date:20160429

>>If we then want the test to create clients that connect to that server we'll 
>>need a
mechanism to find out what the in-use port is.
We should do this mass-change to avoid bind-exception failure. Similarly for 
JMX port.I can see many tests are using this concerned pattern.
Probably for single locator test we can have port "0" functionality.  Let us 
know if we want to add this.



  From: Kirk Lund 
 To: geode ; Hitesh Khamesra 
 
 Sent: Friday, April 29, 2016 4:35 PM
 Subject: Re: Next steps with flickering tests
   
Yes, but the commands for checking status will then always report zero, the
mbeans will report zero, and that is only for the server port. If we then
want the test to create clients that connect to that server we'll need a
mechanism to find out what the in-use port is.

We have a similar problem with locator (and other components). The locator
will fail if you try to pass in zero for a locator port.

So we'll need to alter more code to make sure we can use zero and that
everything that then reports what the port is will fetch the actual port
in-use rather than using zero. But, yes what you're describing is exactly
the solution I think we need to move towards for random ports and
BindException failures.

-Kirk


On Fri, Apr 29, 2016 at 4:10 PM, Hitesh Khamesra <
hitesh...@yahoo.com.invalid> wrote:

> Kirk,
> have we considered following pattern to change..
> from -->
>    int port = AvailablePort.getRandomAvailablePort(AvailablePort.SOCKET);
>    server.setPort(port);
> to ->  server.setPort(0);  port = server.getPort()
> This should take care "bind address" issue.
>
>      From: Kirk Lund 
>  To: geode 
>  Sent: Wednesday, April 27, 2016 7:22 PM
>  Subject: Re: Next steps with flickering tests
>
> We currently have over 10,000 tests but only about 147 are annotated with
> FlakyTest. It probably wouldn't cause precheckin to take much longer. My
> main argument for separating the FlakyTests into their own Jenkins build
> job is to get the main build job 100% green while we know the FlakyTest
> build job might "flicker".
>
> -Kirk
>
>
> On Tue, Apr 26, 2016 at 1:58 PM, Udo Kohlmeyer 
> wrote:
>
> > Depending on the amount of "flaky" tests, this should not increase the
> > time too much.
> > I forsee these "flaky" tests to be few and far in between. Over time I
> > imagine this would be a last resort if we cannot fix the test or even
> > improve the test harness to have a clean test space for each test.
> >
> > --Udo
> >
> >
> > On 27/04/2016 6:42 am, Jens Deppe wrote:
> >
> >> By running the Flakes with forkEvery 1 won't it extend precheckin by a
> >> fair
> >> bit? I'd prefer to see two separate builds running.
> >>
> >> On Tue, Apr 26, 2016 at 11:53 AM, Kirk Lund  wrote:
> >>
> >> I'm in favor of running the FlakyTests together at the end of precheckin
> >>> using forkEvery 1 on them too.
> >>>
> >>> What about running two nightly builds? One that runs all the non-flaky
> >>> UnitTests, IntegrationTests and DistributedTests. Plus another nightly
> >>> build that runs only FlakyTests? We can run Jenkins jobs on our local
> >>> machines that separates FlakyTests out into its own job too, but I'd
> like
> >>> to see the main nightly build go to 100% green (if that's even possible
> >>> without encounter many more flickering tests).
> >>>
> >>> -Kirk
> >>>
> >>>
> >>> On Tue, Apr 26, 2016 at 11:02 AM, Dan Smith  wrote:
> >>>
> >>> +1 for separating these out and running them with forkEvery 1.
> 
>  I think they should probably still run as part of precheckin and the
>  nightly builds though. We don't want this to turn into essentially
>  disabling and ignoring these tests.
> 
>  -Dan
> 
>  On Tue, Apr 26, 2016 at 10:28 AM, Kirk Lund  wrote:
> 
> > Also, I don't think there's much value continuing to use the "CI"
> >
>  label.
> >>>
>  If
> 
> > a test fails in Jenkins, then run the test to see if it fails
> >
>  consistently.
> 
> > If it doesn't, it's flaky. The developer looking at it should try to
> > determine the cause of it failing (ie, "it uses thread sleeps or
> random
> > ports with BindExceptions or has short timeouts with probable GC
> >
>  pause")
> >>>
>  and include that info when adding the FlakyTest annotation and filing
> a
> > Jira bug with the Flaky label. If the test fails consistently, then
> >
>  file
> >>>
>  a
> 
> > Jira bug without the Flaky label.
> >
> > -Kirk
> >
> >
> > On Tue, Apr 26, 2016 at 10:24 AM, Kirk Lund 
> wrote:
> >
> > There are quite a few test classes that have multiple test methods
> >>
> > which
> >>>
>  are annotated with the FlakyTest category.
> >>
> >> More

Spring Data Geode 1.0.0.APACHE-GEODE-INCUBATING-M2 Released

2016-04-29 Thread John Blum

Hi all-

I am happy to announce the release of Spring Data Geode
1.0.0.APACHE-GEODE-INCUBATING-M2 release.

In a nutshell, this is Spring Data GemFire with support for Apache Geode
rebranded, with a separate artifact and version available from Maven
Central.  Highlights include...

* Off-Heap Memory support
* Continuous Query (CQ)
* Multi-Site WAN topology configuration

While CQ and WAN functionality existed in Pivotal GemFire, it was only
recently released as open source in Apache Geode.  Off-Heap is new and SD
Geode has you covered.

For more details, see my blog post and tweet.

https://spring.io/blog/2016/04/29/spring-data-geode-1-0-0-apache-geode-incubating-m2-released
https://twitter.com/john_blum/status/726195512051814401

Feedback welcomed.

Thank you,

John Blum

Re: Next steps with flickering tests

Yes, but the commands for checking status will then always report zero, the
mbeans will report zero, and that is only for the server port. If we then
want the test to create clients that connect to that server we'll need a
mechanism to find out what the in-use port is.

We have a similar problem with locator (and other components). The locator
will fail if you try to pass in zero for a locator port.

So we'll need to alter more code to make sure we can use zero and that
everything that then reports what the port is will fetch the actual port
in-use rather than using zero. But, yes what you're describing is exactly
the solution I think we need to move towards for random ports and
BindException failures.

-Kirk


On Fri, Apr 29, 2016 at 4:10 PM, Hitesh Khamesra <
hitesh...@yahoo.com.invalid> wrote:

> Kirk,
> have we considered following pattern to change..
> from -->
>int port = AvailablePort.getRandomAvailablePort(AvailablePort.SOCKET);
> server.setPort(port);
> to ->  server.setPort(0);  port = server.getPort()
> This should take care "bind address" issue.
>
>   From: Kirk Lund 
>  To: geode 
>  Sent: Wednesday, April 27, 2016 7:22 PM
>  Subject: Re: Next steps with flickering tests
>
> We currently have over 10,000 tests but only about 147 are annotated with
> FlakyTest. It probably wouldn't cause precheckin to take much longer. My
> main argument for separating the FlakyTests into their own Jenkins build
> job is to get the main build job 100% green while we know the FlakyTest
> build job might "flicker".
>
> -Kirk
>
>
> On Tue, Apr 26, 2016 at 1:58 PM, Udo Kohlmeyer 
> wrote:
>
> > Depending on the amount of "flaky" tests, this should not increase the
> > time too much.
> > I forsee these "flaky" tests to be few and far in between. Over time I
> > imagine this would be a last resort if we cannot fix the test or even
> > improve the test harness to have a clean test space for each test.
> >
> > --Udo
> >
> >
> > On 27/04/2016 6:42 am, Jens Deppe wrote:
> >
> >> By running the Flakes with forkEvery 1 won't it extend precheckin by a
> >> fair
> >> bit? I'd prefer to see two separate builds running.
> >>
> >> On Tue, Apr 26, 2016 at 11:53 AM, Kirk Lund  wrote:
> >>
> >> I'm in favor of running the FlakyTests together at the end of precheckin
> >>> using forkEvery 1 on them too.
> >>>
> >>> What about running two nightly builds? One that runs all the non-flaky
> >>> UnitTests, IntegrationTests and DistributedTests. Plus another nightly
> >>> build that runs only FlakyTests? We can run Jenkins jobs on our local
> >>> machines that separates FlakyTests out into its own job too, but I'd
> like
> >>> to see the main nightly build go to 100% green (if that's even possible
> >>> without encounter many more flickering tests).
> >>>
> >>> -Kirk
> >>>
> >>>
> >>> On Tue, Apr 26, 2016 at 11:02 AM, Dan Smith  wrote:
> >>>
> >>> +1 for separating these out and running them with forkEvery 1.
> 
>  I think they should probably still run as part of precheckin and the
>  nightly builds though. We don't want this to turn into essentially
>  disabling and ignoring these tests.
> 
>  -Dan
> 
>  On Tue, Apr 26, 2016 at 10:28 AM, Kirk Lund  wrote:
> 
> > Also, I don't think there's much value continuing to use the "CI"
> >
>  label.
> >>>
>  If
> 
> > a test fails in Jenkins, then run the test to see if it fails
> >
>  consistently.
> 
> > If it doesn't, it's flaky. The developer looking at it should try to
> > determine the cause of it failing (ie, "it uses thread sleeps or
> random
> > ports with BindExceptions or has short timeouts with probable GC
> >
>  pause")
> >>>
>  and include that info when adding the FlakyTest annotation and filing
> a
> > Jira bug with the Flaky label. If the test fails consistently, then
> >
>  file
> >>>
>  a
> 
> > Jira bug without the Flaky label.
> >
> > -Kirk
> >
> >
> > On Tue, Apr 26, 2016 at 10:24 AM, Kirk Lund 
> wrote:
> >
> > There are quite a few test classes that have multiple test methods
> >>
> > which
> >>>
>  are annotated with the FlakyTest category.
> >>
> >> More thoughts:
> >>
> >> In general, I think that if any given test fails intermittently then
> >>
> > it
> >>>
>  is
> 
> > a FlakyTest. A good test should either pass or fail consistently.
> >>
> > After
> >>>
>  annotating a test method with FlakyTest, the developer should then add
> >>
> > the
> 
> > Flaky label to corresponding Jira ticket. What we then do with the
> >>
> > Jira
> >>>
>  tickets (ie, fix them) is probably more important than deciding if a
> >>
> > test
> 
> > is flaky or not.
> >>
> >>

Re: Next steps with flickering tests

Kirk,
have we considered following pattern to change..
from -->
   int port = AvailablePort.getRandomAvailablePort(AvailablePort.SOCKET);
    server.setPort(port);
to ->  server.setPort(0);  port = server.getPort()
This should take care "bind address" issue.

  From: Kirk Lund 
 To: geode  
 Sent: Wednesday, April 27, 2016 7:22 PM
 Subject: Re: Next steps with flickering tests
   
We currently have over 10,000 tests but only about 147 are annotated with
FlakyTest. It probably wouldn't cause precheckin to take much longer. My
main argument for separating the FlakyTests into their own Jenkins build
job is to get the main build job 100% green while we know the FlakyTest
build job might "flicker".

-Kirk


On Tue, Apr 26, 2016 at 1:58 PM, Udo Kohlmeyer 
wrote:

> Depending on the amount of "flaky" tests, this should not increase the
> time too much.
> I forsee these "flaky" tests to be few and far in between. Over time I
> imagine this would be a last resort if we cannot fix the test or even
> improve the test harness to have a clean test space for each test.
>
> --Udo
>
>
> On 27/04/2016 6:42 am, Jens Deppe wrote:
>
>> By running the Flakes with forkEvery 1 won't it extend precheckin by a
>> fair
>> bit? I'd prefer to see two separate builds running.
>>
>> On Tue, Apr 26, 2016 at 11:53 AM, Kirk Lund  wrote:
>>
>> I'm in favor of running the FlakyTests together at the end of precheckin
>>> using forkEvery 1 on them too.
>>>
>>> What about running two nightly builds? One that runs all the non-flaky
>>> UnitTests, IntegrationTests and DistributedTests. Plus another nightly
>>> build that runs only FlakyTests? We can run Jenkins jobs on our local
>>> machines that separates FlakyTests out into its own job too, but I'd like
>>> to see the main nightly build go to 100% green (if that's even possible
>>> without encounter many more flickering tests).
>>>
>>> -Kirk
>>>
>>>
>>> On Tue, Apr 26, 2016 at 11:02 AM, Dan Smith  wrote:
>>>
>>> +1 for separating these out and running them with forkEvery 1.

 I think they should probably still run as part of precheckin and the
 nightly builds though. We don't want this to turn into essentially
 disabling and ignoring these tests.

 -Dan

 On Tue, Apr 26, 2016 at 10:28 AM, Kirk Lund  wrote:

> Also, I don't think there's much value continuing to use the "CI"
>
 label.
>>>
 If

> a test fails in Jenkins, then run the test to see if it fails
>
 consistently.

> If it doesn't, it's flaky. The developer looking at it should try to
> determine the cause of it failing (ie, "it uses thread sleeps or random
> ports with BindExceptions or has short timeouts with probable GC
>
 pause")
>>>
 and include that info when adding the FlakyTest annotation and filing a
> Jira bug with the Flaky label. If the test fails consistently, then
>
 file
>>>
 a

> Jira bug without the Flaky label.
>
> -Kirk
>
>
> On Tue, Apr 26, 2016 at 10:24 AM, Kirk Lund  wrote:
>
> There are quite a few test classes that have multiple test methods
>>
> which
>>>
 are annotated with the FlakyTest category.
>>
>> More thoughts:
>>
>> In general, I think that if any given test fails intermittently then
>>
> it
>>>
 is

> a FlakyTest. A good test should either pass or fail consistently.
>>
> After
>>>
 annotating a test method with FlakyTest, the developer should then add
>>
> the

> Flaky label to corresponding Jira ticket. What we then do with the
>>
> Jira
>>>
 tickets (ie, fix them) is probably more important than deciding if a
>>
> test

> is flaky or not.
>>
>> Rather than try to come up with some flaky process for determining if
>>
> a
>>>
 given test is flaky (ie, "does it have thread sleeps?"), it would be
>>
> better

> to have a wiki page that has examples of flakiness and how to fix them
>>
> ("if

> the test has thread sleeps, then switch to using Awaitility and do
>> this...").
>>
>> -Kirk
>>
>>
>> On Mon, Apr 25, 2016 at 10:51 PM, Anthony Baker 
>>
> wrote:

> Thanks Kirk!
>>>
>>> ~/code/incubator-geode (develop)$ grep -ro "FlakyTest.class" . | grep
>>>
>> -v

> Binary | wc -l | xargs echo "Flake factor:"
>>> Flake factor: 136
>>>
>>> Anthony
>>>
>>>
>>> On Apr 25, 2016, at 9:45 PM, William Markito 

>>> wrote:
>>>
 +1

 Are we also planning to automate the additional build task somehow

>>> ?
>>>
 I'd also suggest creating a wiki page with some stats (like how

>>>

Re: Review Request 46854: GEODE-1224: Modify BucketRegion.getCloningEnabled to call this.partitionedRegion.getCloningEnabled


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


Ship it!




Ship It!

- Hitesh Khamesra


On April 29, 2016, 10:40 p.m., Scott Jewell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46854/
> ---
> 
> (Updated April 29, 2016, 10:40 p.m.)
> 
> 
> Review request for geode, Darrel Schneider and Ken Howe.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Modified BucketRegion and PRDeltaPropagationDUnitTest
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractRegion.java
>  d37f025d9dc81b938425c277f33b7138951d2252 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/BucketRegion.java
>  f5ae0fb37c9347d5ce8fe18bc1d61fdace941c98 
>   geode-core/src/test/java/com/gemstone/gemfire/DeltaTestImpl.java 
> cd824590ada9652db75f4dd94cd2c0dba3cf9b5a 
>   
> geode-cq/src/test/java/com/gemstone/gemfire/internal/cache/PRDeltaPropagationDUnitTest.java
>  e8816f979f1b1627f7540975a7904065735c016d 
> 
> Diff: https://reviews.apache.org/r/46854/diff/
> 
> 
> Testing
> ---
> 
> precheckin is currently running
> 
> 
> Thanks,
> 
> Scott Jewell
> 
>

Review Request 46854: GEODE-1224: Modify BucketRegion.getCloningEnabled to call this.partitionedRegion.getCloningEnabled

2016-04-29 Thread Scott Jewell


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

Review request for geode, Darrel Schneider and Ken Howe.


Repository: geode


Description
---

Modified BucketRegion and PRDeltaPropagationDUnitTest


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractRegion.java
 d37f025d9dc81b938425c277f33b7138951d2252 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/BucketRegion.java 
f5ae0fb37c9347d5ce8fe18bc1d61fdace941c98 
  geode-core/src/test/java/com/gemstone/gemfire/DeltaTestImpl.java 
cd824590ada9652db75f4dd94cd2c0dba3cf9b5a 
  
geode-cq/src/test/java/com/gemstone/gemfire/internal/cache/PRDeltaPropagationDUnitTest.java
 e8816f979f1b1627f7540975a7904065735c016d 

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


Testing
---

precheckin is currently running


Thanks,

Scott Jewell

Re: What will it take to release geode 1.0?

2016-04-29 Thread Dave Barnes

Ahh, my misunderstanding...I thought '1.0' was synonymous with
'post-incubation'.
We're hoping to convert our docs from DITA to Markdown before contributing
to ASF, still in the early stages of that conversion.
We'll keep plugging away and keep our eye on the software releases.

On Fri, Apr 29, 2016 at 2:58 PM, Dan Smith  wrote:

> I'm not sure if the docs are a prerequisite for graduation. I don't think
> there are specific requirements about the level of documentation for
> graduation, just about community involvement - which docs could help
> encourage :)
>
> In any case we don't need to graduate or even be graduation ready to
> release 1.0. The version number 1.0 has no special meaning to the ASF as
> far as I can tell. But I think having regular releases and having an
> official non-milestone release will help us grow the community.
>
> This page has some information on what's required for graduation:
>
> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements
>
> -Dan
>
>
> On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes  wrote:
>
> > We plan at some point to donate the docs so they'll be incorporated into
> > the repo. Is this a prerequisite to graduating from incubation?
> >
> > On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund  wrote:
> >
> > > The package renaming would most likely break some backwards
> compatibility
> > > between 1.0 and 2.0. I'd prefer to see the packages get renamed before
> > 1.0
> > > so we can change the packages of Message classes, etc in the same
> release
> > > that introduces the new JGroups.
> > >
> > > The packages are currently a mess of com.gemstone.*, com.vmware.*,
> > > joptsimple.*, org.json.* (would we change all four or just the
> > > gemstone/vmware packages?).
> > >
> > > I'm probably biting off more than I should, but I'd be willing head up
> > the
> > > package renaming effort.
> > >
> > > I think maintaining backwards compatibility (rolling upgrades included)
> > for
> > > releases following Geode 1.0 is a definite requirement. I'd like to see
> > the
> > > other discussion thread about defining the Geode protocol(s) converge
> > with
> > > this thread. Officially defining the communication protocols (cluster,
> > > client/server, etc) would ideally happen in conjunction with 1.0 so
> that
> > > it's concrete and less ambiguous for 2.0 and later releases.
> > >
> > > -Kirk
> > >
> > >
> > > On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith  wrote:
> > >
> > > > We've been releasing milestones of 1.0, but at some point we actually
> > > have
> > > > to release a real geode 1.0 :)
> > > >
> > > > What is keeping us from releasing geode 1.0 at this point? Just the
> > > issues
> > > > currently marked with Fix Version M3? I think we should nail down the
> > > scope
> > > > of 1.0 and track our progress to the 1.0 release.
> > > >
> > > > From the apache process perspective, I don't think 1.0 is any
> different
> > > > from the milestone releases we've done so far. The only difference
> with
> > > 1.0
> > > > is what it means to the geode community.
> > > >
> > > > Gemfire maintained backwards compatibility with previous releases for
> > > > persistent files, client/server, WAN, and P2P messaging. I think once
> > we
> > > > release 1.0 we should provide that same guarantee that the next geode
> > > > release will be backwards compatible with 1.0.
> > > >
> > > > We do still have the package renaming (GEODE-37) on the horizon. My
> > > > suggestion is that in the interests of getting 1.0 out the door, at
> > this
> > > > point we should just release geode 1.0 with the old packages and
> rename
> > > > packages in geode 2.0.
> > > >
> > > > Thoughts?
> > > >
> > > > -Dan
> > > >
> > >
> >
>

Re: What will it take to release geode 1.0?

2016-04-29 Thread Dan Smith

I'm not sure if the docs are a prerequisite for graduation. I don't think
there are specific requirements about the level of documentation for
graduation, just about community involvement - which docs could help
encourage :)

In any case we don't need to graduate or even be graduation ready to
release 1.0. The version number 1.0 has no special meaning to the ASF as
far as I can tell. But I think having regular releases and having an
official non-milestone release will help us grow the community.

This page has some information on what's required for graduation:
http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements

-Dan


On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes  wrote:

> We plan at some point to donate the docs so they'll be incorporated into
> the repo. Is this a prerequisite to graduating from incubation?
>
> On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund  wrote:
>
> > The package renaming would most likely break some backwards compatibility
> > between 1.0 and 2.0. I'd prefer to see the packages get renamed before
> 1.0
> > so we can change the packages of Message classes, etc in the same release
> > that introduces the new JGroups.
> >
> > The packages are currently a mess of com.gemstone.*, com.vmware.*,
> > joptsimple.*, org.json.* (would we change all four or just the
> > gemstone/vmware packages?).
> >
> > I'm probably biting off more than I should, but I'd be willing head up
> the
> > package renaming effort.
> >
> > I think maintaining backwards compatibility (rolling upgrades included)
> for
> > releases following Geode 1.0 is a definite requirement. I'd like to see
> the
> > other discussion thread about defining the Geode protocol(s) converge
> with
> > this thread. Officially defining the communication protocols (cluster,
> > client/server, etc) would ideally happen in conjunction with 1.0 so that
> > it's concrete and less ambiguous for 2.0 and later releases.
> >
> > -Kirk
> >
> >
> > On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith  wrote:
> >
> > > We've been releasing milestones of 1.0, but at some point we actually
> > have
> > > to release a real geode 1.0 :)
> > >
> > > What is keeping us from releasing geode 1.0 at this point? Just the
> > issues
> > > currently marked with Fix Version M3? I think we should nail down the
> > scope
> > > of 1.0 and track our progress to the 1.0 release.
> > >
> > > From the apache process perspective, I don't think 1.0 is any different
> > > from the milestone releases we've done so far. The only difference with
> > 1.0
> > > is what it means to the geode community.
> > >
> > > Gemfire maintained backwards compatibility with previous releases for
> > > persistent files, client/server, WAN, and P2P messaging. I think once
> we
> > > release 1.0 we should provide that same guarantee that the next geode
> > > release will be backwards compatible with 1.0.
> > >
> > > We do still have the package renaming (GEODE-37) on the horizon. My
> > > suggestion is that in the interests of getting 1.0 out the door, at
> this
> > > point we should just release geode 1.0 with the old packages and rename
> > > packages in geode 2.0.
> > >
> > > Thoughts?
> > >
> > > -Dan
> > >
> >
>

Re: What will it take to release geode 1.0?

2016-04-29 Thread Dave Barnes

We plan at some point to donate the docs so they'll be incorporated into
the repo. Is this a prerequisite to graduating from incubation?

On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund  wrote:

> The package renaming would most likely break some backwards compatibility
> between 1.0 and 2.0. I'd prefer to see the packages get renamed before 1.0
> so we can change the packages of Message classes, etc in the same release
> that introduces the new JGroups.
>
> The packages are currently a mess of com.gemstone.*, com.vmware.*,
> joptsimple.*, org.json.* (would we change all four or just the
> gemstone/vmware packages?).
>
> I'm probably biting off more than I should, but I'd be willing head up the
> package renaming effort.
>
> I think maintaining backwards compatibility (rolling upgrades included) for
> releases following Geode 1.0 is a definite requirement. I'd like to see the
> other discussion thread about defining the Geode protocol(s) converge with
> this thread. Officially defining the communication protocols (cluster,
> client/server, etc) would ideally happen in conjunction with 1.0 so that
> it's concrete and less ambiguous for 2.0 and later releases.
>
> -Kirk
>
>
> On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith  wrote:
>
> > We've been releasing milestones of 1.0, but at some point we actually
> have
> > to release a real geode 1.0 :)
> >
> > What is keeping us from releasing geode 1.0 at this point? Just the
> issues
> > currently marked with Fix Version M3? I think we should nail down the
> scope
> > of 1.0 and track our progress to the 1.0 release.
> >
> > From the apache process perspective, I don't think 1.0 is any different
> > from the milestone releases we've done so far. The only difference with
> 1.0
> > is what it means to the geode community.
> >
> > Gemfire maintained backwards compatibility with previous releases for
> > persistent files, client/server, WAN, and P2P messaging. I think once we
> > release 1.0 we should provide that same guarantee that the next geode
> > release will be backwards compatible with 1.0.
> >
> > We do still have the package renaming (GEODE-37) on the horizon. My
> > suggestion is that in the interests of getting 1.0 out the door, at this
> > point we should just release geode 1.0 with the old packages and rename
> > packages in geode 2.0.
> >
> > Thoughts?
> >
> > -Dan
> >
>

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #294 has FAILED (21 tests failed). Change made by 4 authors.

2016-04-29 Thread Spring CI


---
Spring Data GemFire > Nightly-ApacheGeode > #294 failed.
---
Scheduled with changes by Mark Paluch , John Blum 
, Spring Buildmaster, Oliver Gierke.
21/1401 tests failed.

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

-
Currently Responsible
-

John Blum 



--
Failing Jobs
--
  - Default Job (Default Stage): 21 of 1401 tests failed.



--
Code Changes
--
Spring Buildmaster (0dee4d4da45e8b4bc725b57cc1a246eeac2e0466):

>Prepare next development iteration.

Spring Buildmaster (a304d5a5704e9daf002ec312a0733437a1cc41f8):

>

John Blum  (f904f6ad867db497a0353ed83d1dbf8ecfd82335):

>SGF-490 - Re-instate GemFire WAN and CQ functionality.



--
Tests
--
New Test Failures (21)
   - LocalRegionNamespaceTest: Simple local region
   - LocalRegionNamespaceTest: Complex local
   - LocalRegionNamespaceTest: Publisher local region
   - LocalRegionNamespaceTest: Region lookup
   - LocalRegionNamespaceTest: Local persistent
   - LocalRegionNamespaceTest: Compressed local region
   - LocalRegionNamespaceTest: Local with attributes
   - PartitionedRegionNamespaceTest: Options partition region
   - PartitionedRegionNamespaceTest: Compressed partition region
   - PartitionedRegionNamespaceTest: Multiple partition listeners
   - PartitionedRegionNamespaceTest: Simple partition region
   - PartitionedRegionNamespaceTest: Fixed partition region
   - PartitionedRegionNamespaceTest: Single partition listeners
   - PartitionedRegionNamespaceTest: Complex partition region
   - ReplicatedRegionNamespaceTest: Replicated region with attributes
   - ReplicatedRegionNamespaceTest: Publish replicate region
   - ReplicatedRegionNamespaceTest: Region lookup
   - ReplicatedRegionNamespaceTest: Replicated with synchronous index updates
   - ReplicatedRegionNamespaceTest: Complex replicate region
   - ReplicatedRegionNamespaceTest: Compressed replicate region
   - ReplicatedRegionNamespaceTest: Simple replicate region

--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 46850: GEODE-1329 auto-reconnect attempts cease if kicked out during boot-up of the cache

2016-04-29 Thread Bruce Schuchardt

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

(Updated April 29, 2016, 8:31 p.m.)

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

Changes
---

Missed a couple of "continues" in exception handlers

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

Repository: geode

Description
---

Users would like auto-reconnect to ensure that a node retries even if it has
been immediately kicked out of the distributed system.
InternalDistributedSystem.reconnect() now includes cache-creation in its retry
loop and, should the cache fail to start due to a CancelException it will shut
down and try again.

While creating a new test in ReconnectDUnitTest I found problems with the other
tests in that class that I fixed. Notably the method
getDistributedSystemProperties() wasn't returning the correct properties for a
lot of test cases because the dsProperties variable wasn't being set by them
and they were using the getCache() method. This was causing the current
distributed system to be destroyed and a new one created with different
properties than the test wanted. That was causing periodic test failures.

Diffs (updated)
-

geode-core/src/main/java/com/gemstone/gemfire/distributed/DistributedSystem.java
1de675d6d5492c0f418f000fff2b2a47cc0704b2

geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/InternalDistributedSystem.java
3ef8e80e031672b26f34c9896d76e72fab2b9d48

geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DistributedRegion.java
226d914c2f28677ca39cf8f0bcda2d2783cd2076

geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java
c4774668e14834f15f1de7b029e5ef2ad1fe20e8
geode-core/src/test/java/com/gemstone/gemfire/cache30/ReconnectDUnitTest.java
a4ba33def4745fbdebac1eb0ce90b75246197ec5

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

Testing
---

New unit test. Precheckin is running. Multihost network partition testing.

Thanks,

Bruce Schuchardt

Re: What will it take to release geode 1.0?

2016-04-29 Thread Michael Stolz

+1

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771
On Apr 29, 2016 11:59 AM, "Dan Smith"  wrote:

> We've been releasing milestones of 1.0, but at some point we actually have
> to release a real geode 1.0 :)
>
> What is keeping us from releasing geode 1.0 at this point? Just the issues
> currently marked with Fix Version M3? I think we should nail down the scope
> of 1.0 and track our progress to the 1.0 release.
>
> From the apache process perspective, I don't think 1.0 is any different
> from the milestone releases we've done so far. The only difference with 1.0
> is what it means to the geode community.
>
> Gemfire maintained backwards compatibility with previous releases for
> persistent files, client/server, WAN, and P2P messaging. I think once we
> release 1.0 we should provide that same guarantee that the next geode
> release will be backwards compatible with 1.0.
>
> We do still have the package renaming (GEODE-37) on the horizon. My
> suggestion is that in the interests of getting 1.0 out the door, at this
> point we should just release geode 1.0 with the old packages and rename
> packages in geode 2.0.
>
> Thoughts?
>
> -Dan
>

What will it take to release geode 1.0?

2016-04-29 Thread Dan Smith

We've been releasing milestones of 1.0, but at some point we actually have
to release a real geode 1.0 :)

What is keeping us from releasing geode 1.0 at this point? Just the issues
currently marked with Fix Version M3? I think we should nail down the scope
of 1.0 and track our progress to the 1.0 release.

>From the apache process perspective, I don't think 1.0 is any different
from the milestone releases we've done so far. The only difference with 1.0
is what it means to the geode community.

Gemfire maintained backwards compatibility with previous releases for
persistent files, client/server, WAN, and P2P messaging. I think once we
release 1.0 we should provide that same guarantee that the next geode
release will be backwards compatible with 1.0.

We do still have the package renaming (GEODE-37) on the horizon. My
suggestion is that in the interests of getting 1.0 out the door, at this
point we should just release geode 1.0 with the old packages and rename
packages in geode 2.0.

Thoughts?

-Dan

Review Request 46850: GEODE-1329 auto-reconnect attempts cease if kicked out during boot-up of the cache

2016-04-29 Thread Bruce Schuchardt

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

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

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

Repository: geode

Description
---

Diffs
-

geode-core/src/main/java/com/gemstone/gemfire/distributed/DistributedSystem.java
1de675d6d5492c0f418f000fff2b2a47cc0704b2

geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/InternalDistributedSystem.java
3ef8e80e031672b26f34c9896d76e72fab2b9d48

geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DistributedRegion.java
226d914c2f28677ca39cf8f0bcda2d2783cd2076

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

Testing
---

New unit test. Precheckin is running. Multihost network partition testing.

Thanks,

Bruce Schuchardt

Re: Need gradle expertise on checkMissedTests

Works for me too, though I just ended up
with @PowerMockIgnore("*.IntegrationTest")

Thanks!


On Fri, Apr 29, 2016 at 11:22 AM, Jens Deppe  wrote:

> Or, more readably:
>
> *@Category(IntegrationTest.class)*
> @PrepareForTest(Repository.class)
> @RunWith(PowerMockRunner.class)
> @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
> @WebAppConfiguration
> @ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
> *@PowerMockIgnore({"*.IntegrationTest", "*.UnitTest"})*
>
>
>
>
> On Fri, Apr 29, 2016 at 11:21 AM, Jens Deppe  wrote:
>
> > This works for me:
> >
> > @Category(IntegrationTest.class)
> > @PrepareForTest(Repository.class)
> > @RunWith(PowerMockRunner.class)
> > @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
> > @WebAppConfiguration
> > @ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
> > @PowerMockIgnore({"*.IntegrationTest", "*.UnitTest"})
> >
> >
> > On Fri, Apr 29, 2016 at 11:07 AM, Jens Deppe  wrote:
> >
> >> Did you try and mess with the PowerMockIgnore annotation?
> >>
> >> On Fri, Apr 29, 2016 at 10:57 AM, Kirk Lund  wrote:
> >>
> >>> I'm trying to change the *Test category on a test from UnitTest to
> >>> IntegrationTest, but doing so causes this file (and only this one) to
> >>> fail
> >>> checkMissedTests.
> >>>
> >>> Take a look at:
> >>>
> >>>
> >>>
> geode-pulse/src/test/java/com/vmware/gemfire/tools/pulse/controllers/PulseControllerJUnitTest.java
> >>>
> >>> You'll see this test has a lot of annotations on the class:
> >>>
> >>> @Category(UnitTest.class)
> >>> @PrepareForTest(Repository.class)
> >>> @RunWith(PowerMockRunner.class)
> >>> @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
> >>> @WebAppConfiguration
> >>> @ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
> >>> @PowerMockIgnore("*.UnitTest")
> >>>
> >>> Any ideas why checkMissedTests fails when I change this to an
> >>> IntegrationTest?
> >>>
> >>> @Category(IntegrationTest.class)
> >>> @PrepareForTest(Repository.class)
> >>> @RunWith(PowerMockRunner.class)
> >>> @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
> >>> @WebAppConfiguration
> >>> @ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
> >>> @PowerMockIgnore("*.UnitTest")
> >>>
> >>> The following is the failure when it's marked as an IntegrationTest.
> If I
> >>> change it back to UnitTest, it passes checkMissedTests.
> >>>
> >>> FAILURE: Build failed with an exception.
> >>>
> >>> * Where:
> >>> Script '/Users/klund/dev/gemfire/open/gradle/test.gradle' line: 84
> >>>
> >>> * What went wrong:
> >>> Execution failed for task ':geode-pulse:checkMissedTests'.
> >>> > The test
> >>>
> >>>
> *com.vmware.gemfire.tools.pulse.controllers.PulseControllerJUnitTest.clearAlerts*
> >>> does not include a junit category.
> >>>
> >>> * Try:
> >>> Run with --stacktrace option to get the stack trace. Run with --info or
> >>> --debug option to get more log output.
> >>>
> >>> BUILD FAILED
> >>>
> >>> Total time: 48.0 secs
> >>>
> >>> -Kirk
> >>>
> >>
> >>
> >
>

Re: Need gradle expertise on checkMissedTests

Or, more readably:

*@Category(IntegrationTest.class)*
@PrepareForTest(Repository.class)
@RunWith(PowerMockRunner.class)
@PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
@ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
*@PowerMockIgnore({"*.IntegrationTest", "*.UnitTest"})*




On Fri, Apr 29, 2016 at 11:21 AM, Jens Deppe  wrote:

> This works for me:
>
> @Category(IntegrationTest.class)
> @PrepareForTest(Repository.class)
> @RunWith(PowerMockRunner.class)
> @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
> @WebAppConfiguration
> @ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
> @PowerMockIgnore({"*.IntegrationTest", "*.UnitTest"})
>
>
> On Fri, Apr 29, 2016 at 11:07 AM, Jens Deppe  wrote:
>
>> Did you try and mess with the PowerMockIgnore annotation?
>>
>> On Fri, Apr 29, 2016 at 10:57 AM, Kirk Lund  wrote:
>>
>>> I'm trying to change the *Test category on a test from UnitTest to
>>> IntegrationTest, but doing so causes this file (and only this one) to
>>> fail
>>> checkMissedTests.
>>>
>>> Take a look at:
>>>
>>>
>>> geode-pulse/src/test/java/com/vmware/gemfire/tools/pulse/controllers/PulseControllerJUnitTest.java
>>>
>>> You'll see this test has a lot of annotations on the class:
>>>
>>> @Category(UnitTest.class)
>>> @PrepareForTest(Repository.class)
>>> @RunWith(PowerMockRunner.class)
>>> @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
>>> @WebAppConfiguration
>>> @ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
>>> @PowerMockIgnore("*.UnitTest")
>>>
>>> Any ideas why checkMissedTests fails when I change this to an
>>> IntegrationTest?
>>>
>>> @Category(IntegrationTest.class)
>>> @PrepareForTest(Repository.class)
>>> @RunWith(PowerMockRunner.class)
>>> @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
>>> @WebAppConfiguration
>>> @ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
>>> @PowerMockIgnore("*.UnitTest")
>>>
>>> The following is the failure when it's marked as an IntegrationTest. If I
>>> change it back to UnitTest, it passes checkMissedTests.
>>>
>>> FAILURE: Build failed with an exception.
>>>
>>> * Where:
>>> Script '/Users/klund/dev/gemfire/open/gradle/test.gradle' line: 84
>>>
>>> * What went wrong:
>>> Execution failed for task ':geode-pulse:checkMissedTests'.
>>> > The test
>>>
>>> *com.vmware.gemfire.tools.pulse.controllers.PulseControllerJUnitTest.clearAlerts*
>>> does not include a junit category.
>>>
>>> * Try:
>>> Run with --stacktrace option to get the stack trace. Run with --info or
>>> --debug option to get more log output.
>>>
>>> BUILD FAILED
>>>
>>> Total time: 48.0 secs
>>>
>>> -Kirk
>>>
>>
>>
>

Re: Need gradle expertise on checkMissedTests

This works for me:

@Category(IntegrationTest.class)
@PrepareForTest(Repository.class)
@RunWith(PowerMockRunner.class)
@PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
@ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
@PowerMockIgnore({"*.IntegrationTest", "*.UnitTest"})


On Fri, Apr 29, 2016 at 11:07 AM, Jens Deppe  wrote:

> Did you try and mess with the PowerMockIgnore annotation?
>
> On Fri, Apr 29, 2016 at 10:57 AM, Kirk Lund  wrote:
>
>> I'm trying to change the *Test category on a test from UnitTest to
>> IntegrationTest, but doing so causes this file (and only this one) to fail
>> checkMissedTests.
>>
>> Take a look at:
>>
>>
>> geode-pulse/src/test/java/com/vmware/gemfire/tools/pulse/controllers/PulseControllerJUnitTest.java
>>
>> You'll see this test has a lot of annotations on the class:
>>
>> @Category(UnitTest.class)
>> @PrepareForTest(Repository.class)
>> @RunWith(PowerMockRunner.class)
>> @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
>> @WebAppConfiguration
>> @ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
>> @PowerMockIgnore("*.UnitTest")
>>
>> Any ideas why checkMissedTests fails when I change this to an
>> IntegrationTest?
>>
>> @Category(IntegrationTest.class)
>> @PrepareForTest(Repository.class)
>> @RunWith(PowerMockRunner.class)
>> @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
>> @WebAppConfiguration
>> @ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
>> @PowerMockIgnore("*.UnitTest")
>>
>> The following is the failure when it's marked as an IntegrationTest. If I
>> change it back to UnitTest, it passes checkMissedTests.
>>
>> FAILURE: Build failed with an exception.
>>
>> * Where:
>> Script '/Users/klund/dev/gemfire/open/gradle/test.gradle' line: 84
>>
>> * What went wrong:
>> Execution failed for task ':geode-pulse:checkMissedTests'.
>> > The test
>>
>> *com.vmware.gemfire.tools.pulse.controllers.PulseControllerJUnitTest.clearAlerts*
>> does not include a junit category.
>>
>> * Try:
>> Run with --stacktrace option to get the stack trace. Run with --info or
>> --debug option to get more log output.
>>
>> BUILD FAILED
>>
>> Total time: 48.0 secs
>>
>> -Kirk
>>
>
>

Re: Need gradle expertise on checkMissedTests

I'm unsure what "@PowerMockIgnore("*.UnitTest")" is specifying. Is it
specifying PulseControllerJ*UnitTest* for ignore or is it specifying
@Category*(UnitTest.*class) for ignore?

-Kirk


On Fri, Apr 29, 2016 at 11:07 AM, Jens Deppe  wrote:

> Did you try and mess with the PowerMockIgnore annotation?
>
> On Fri, Apr 29, 2016 at 10:57 AM, Kirk Lund  wrote:
>
> > I'm trying to change the *Test category on a test from UnitTest to
> > IntegrationTest, but doing so causes this file (and only this one) to
> fail
> > checkMissedTests.
> >
> > Take a look at:
> >
> >
> >
> geode-pulse/src/test/java/com/vmware/gemfire/tools/pulse/controllers/PulseControllerJUnitTest.java
> >
> > You'll see this test has a lot of annotations on the class:
> >
> > @Category(UnitTest.class)
> > @PrepareForTest(Repository.class)
> > @RunWith(PowerMockRunner.class)
> > @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
> > @WebAppConfiguration
> > @ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
> > @PowerMockIgnore("*.UnitTest")
> >
> > Any ideas why checkMissedTests fails when I change this to an
> > IntegrationTest?
> >
> > @Category(IntegrationTest.class)
> > @PrepareForTest(Repository.class)
> > @RunWith(PowerMockRunner.class)
> > @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
> > @WebAppConfiguration
> > @ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
> > @PowerMockIgnore("*.UnitTest")
> >
> > The following is the failure when it's marked as an IntegrationTest. If I
> > change it back to UnitTest, it passes checkMissedTests.
> >
> > FAILURE: Build failed with an exception.
> >
> > * Where:
> > Script '/Users/klund/dev/gemfire/open/gradle/test.gradle' line: 84
> >
> > * What went wrong:
> > Execution failed for task ':geode-pulse:checkMissedTests'.
> > > The test
> >
> >
> *com.vmware.gemfire.tools.pulse.controllers.PulseControllerJUnitTest.clearAlerts*
> > does not include a junit category.
> >
> > * Try:
> > Run with --stacktrace option to get the stack trace. Run with --info or
> > --debug option to get more log output.
> >
> > BUILD FAILED
> >
> > Total time: 48.0 secs
> >
> > -Kirk
> >
>

Release manager volunteer for the next release?

2016-04-29 Thread Dan Smith

With M2 done, it's time to talk about that next release of geode.

Are there any volunteers to be the release manager for the next release? I
can do it, but when talking about M2 we decided it was a good idea to
rotate release managers so that more people learn about the process.

I went ahead and created an M3 wiki page:
https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M3+Release

That page is currently pulling in all of the issues with the Fix Version of
M3.

-Dan

Re: Need gradle expertise on checkMissedTests

Did you try and mess with the PowerMockIgnore annotation?

On Fri, Apr 29, 2016 at 10:57 AM, Kirk Lund  wrote:

> I'm trying to change the *Test category on a test from UnitTest to
> IntegrationTest, but doing so causes this file (and only this one) to fail
> checkMissedTests.
>
> Take a look at:
>
>
> geode-pulse/src/test/java/com/vmware/gemfire/tools/pulse/controllers/PulseControllerJUnitTest.java
>
> You'll see this test has a lot of annotations on the class:
>
> @Category(UnitTest.class)
> @PrepareForTest(Repository.class)
> @RunWith(PowerMockRunner.class)
> @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
> @WebAppConfiguration
> @ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
> @PowerMockIgnore("*.UnitTest")
>
> Any ideas why checkMissedTests fails when I change this to an
> IntegrationTest?
>
> @Category(IntegrationTest.class)
> @PrepareForTest(Repository.class)
> @RunWith(PowerMockRunner.class)
> @PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
> @WebAppConfiguration
> @ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
> @PowerMockIgnore("*.UnitTest")
>
> The following is the failure when it's marked as an IntegrationTest. If I
> change it back to UnitTest, it passes checkMissedTests.
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Script '/Users/klund/dev/gemfire/open/gradle/test.gradle' line: 84
>
> * What went wrong:
> Execution failed for task ':geode-pulse:checkMissedTests'.
> > The test
>
> *com.vmware.gemfire.tools.pulse.controllers.PulseControllerJUnitTest.clearAlerts*
> does not include a junit category.
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output.
>
> BUILD FAILED
>
> Total time: 48.0 secs
>
> -Kirk
>

Need gradle expertise on checkMissedTests

I'm trying to change the *Test category on a test from UnitTest to
IntegrationTest, but doing so causes this file (and only this one) to fail
checkMissedTests.

Take a look at:

geode-pulse/src/test/java/com/vmware/gemfire/tools/pulse/controllers/PulseControllerJUnitTest.java

You'll see this test has a lot of annotations on the class:

@Category(UnitTest.class)
@PrepareForTest(Repository.class)
@RunWith(PowerMockRunner.class)
@PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
@ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
@PowerMockIgnore("*.UnitTest")

Any ideas why checkMissedTests fails when I change this to an
IntegrationTest?

@Category(IntegrationTest.class)
@PrepareForTest(Repository.class)
@RunWith(PowerMockRunner.class)
@PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
@ContextConfiguration("classpath*:mvc-dispatcher-servlet.xml")
@PowerMockIgnore("*.UnitTest")

The following is the failure when it's marked as an IntegrationTest. If I
change it back to UnitTest, it passes checkMissedTests.

FAILURE: Build failed with an exception.

* Where:
Script '/Users/klund/dev/gemfire/open/gradle/test.gradle' line: 84

* What went wrong:
Execution failed for task ':geode-pulse:checkMissedTests'.
> The test
*com.vmware.gemfire.tools.pulse.controllers.PulseControllerJUnitTest.clearAlerts*
does not include a junit category.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.

BUILD FAILED

Total time: 48.0 secs

-Kirk

Re: Review Request 46837: Additional GEODE-17 review: enhance the GeodeSecurityUtil and review changes


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


Ship it!




Ship It!

- Kirk Lund


On April 29, 2016, 3:34 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46837/
> ---
> 
> (Updated April 29, 2016, 3:34 p.m.)
> 
> 
> Review request for geode, Jens Deppe and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Merge branch 'develop' into feature/GEODE-17-2
> 
> 
> GEODE-17: enhance the GeodeSecurityUtil and review changes
> 
> * allow operations that does not require any authorizations
> * put/get, import/export and locate entry will check region access
> * rename EnvronmentVariablesHandlerInterceptor
> * rename ShiroUtil to GeodeSecurityUtil
> * reformat code and review changes
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/OperationContext.java
>  dd290c5d6b67738b24872b29f4ad08cac7944bc9 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/DistributedSystemMXBean.java
>  a27d92f96b083f700cf0dc356c9c522f737bc861 
>   geode-core/src/main/java/com/gemstone/gemfire/management/MemberMXBean.java 
> 5f656a935883897d20c1b650c04ef12357c66413 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  cdbd3db5983fdb67221125a9e14e5cb2d69a6870 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/DataCommands.java
>  c1c04a31b73732511531bbfda1f4c9c58dc5624f 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/RegionCommands.java
>  ac69d32a3061e8857c94de6577731ee5e572b2ac 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/remote/CommandProcessor.java
>  87053ccecf155a40a1528715119da4d0c29a85fd 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/AccessControlMBean.java
>  992153842e325c3ab228ff7642ff614185392f6b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/MBeanServerWrapper.java
>  bbc044239f6cae631d3b15b2d61de4ef21743a7a 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/ResourceOperation.java
>  f72a83524332ad33aa1e2a91b5aa5072c9b721ff 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/ResourceOperationContext.java
>  396cdace6dc7dc633db71c72e72bce14b94263b7 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/AbstractCommandsController.java
>  211d0b1b785807e6046f6b9a8fe35121379ac595 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/support/EnvironmentVariablesHandlerInterceptor.java
>  bb7a27d4c6639e20f0f41e2c594a30632338ad25 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/shell/RestHttpOperationInvoker.java
>  439e2b4397cf82df172a257faf1469e1984d5a57 
>   geode-core/src/main/java/com/gemstone/gemfire/security/CustomAuthRealm.java 
> 76fc8521772c5cf073dd23dae607b1ab818e3014 
>   
> geode-core/src/main/java/com/gemstone/gemfire/security/JMXShiroAuthenticator.java
>  8f86c38b4fd377082305c14756b8772c71abc9e4 
>   geode-core/src/main/java/com/gemstone/gemfire/security/ShiroUtil.java 
> 01914e42f56b89552f23ef8801139e5288de377e 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/FixedPRSinglehopDUnitTest.java
>  61ea97a7112de029232a97eb997830392445b599 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/CacheServerMBeanAuthorizationJUnitTest.java
>  baa8393bff6989145d14c5a9808c0fa53e8b8a9c 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/CacheServerMBeanShiroJUnitTest.java
>  e55623d4103367c095ea82303ba172adc71c8b2b 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/CliCommandsSecurityTest.java
>  5e49f9270bd67f1468f87a57b9bfafa719816982 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/DataCommandsSecurityTest.java
>  7517f498bf4648a975b3e59b1736d3ba3203172f 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/DiskStoreMXBeanSecurityJUnitTest.java
>  f2487367f6b8b7f747bdd641dc071acf57c2157f 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/GatewayReceiverMBeanSecurityTest.java
>  b28069f560d4ce68036a689444df2cd4733fa2d5 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/GatewaySenderMBeanSecurityTest.java
>  3a9412dab7f16595a02ac02d3e095525a5cc942b 
>   
>

Re: Review Request 46841: GEODE-1326: Add test for gfsh function execution with ResultCollector


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


Fix it, then Ship it!




Fix it and ship it!


geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/FunctionCommandsDUnitTest.java
 (line 190)


change asserts to assertTrue so the test doesn't depend on enabling of java 
assertions

you have the next test correct!


- Kirk Lund


On April 29, 2016, 4:23 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46841/
> ---
> 
> (Updated April 29, 2016, 4:23 p.m.)
> 
> 
> Review request for geode, Jinmei Liao and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1326: Add test for gfsh function execution with ResultCollector
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/FunctionCommandsDUnitTest.java
>  b4d4df1cb96f521b38a0554e2e31658558c6abda 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/ToUpperResultCollector.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46841/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Re: Review Request 46843: GEODE-1324: Convert SessionReplicationIntegrationJUnitTest to use TemporaryFolder


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


Ship it!




Ship It!

- Kirk Lund


On April 29, 2016, 4:34 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46843/
> ---
> 
> (Updated April 29, 2016, 4:34 p.m.)
> 
> 
> Review request for geode, Jinmei Liao and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1324: Convert SessionReplicationIntegrationJUnitTest to use 
> TemporaryFolder
> 
> 
> Diffs
> -
> 
>   
> extensions/geode-modules-session/src/test/java/com/gemstone/gemfire/modules/session/internal/filter/SessionReplicationIntegrationJUnitTest.java
>  004f9fedd02c4ce496bcafae3fd1bbdef506a632 
> 
> Diff: https://reviews.apache.org/r/46843/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Re: Review Request 46837: Additional GEODE-17 review: enhance the GeodeSecurityUtil and review changes



> On April 29, 2016, 5:01 p.m., Kirk Lund wrote:
> > geode-core/src/main/java/com/gemstone/gemfire/security/ShiroUtil.java, line 
> > 18
> > 
> >
> > I still want to see this moved to "package 
> > com.gemstone.gemfire.internal.security;"
> > 
> > com.gemstone.gemfire.security sets a precedent for backwards 
> > compatibility and essentially ties us permanently to this as a customer API.
> > 
> > It also has a quality certification impact which basically says we 
> > expect the users to use this API and we certify that we've tested it in 
> > everyway that the user might use it.

moved to the internal packages


- Jinmei


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


On April 29, 2016, 3:34 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46837/
> ---
> 
> (Updated April 29, 2016, 3:34 p.m.)
> 
> 
> Review request for geode, Jens Deppe and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Merge branch 'develop' into feature/GEODE-17-2
> 
> 
> GEODE-17: enhance the GeodeSecurityUtil and review changes
> 
> * allow operations that does not require any authorizations
> * put/get, import/export and locate entry will check region access
> * rename EnvronmentVariablesHandlerInterceptor
> * rename ShiroUtil to GeodeSecurityUtil
> * reformat code and review changes
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/OperationContext.java
>  dd290c5d6b67738b24872b29f4ad08cac7944bc9 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/DistributedSystemMXBean.java
>  a27d92f96b083f700cf0dc356c9c522f737bc861 
>   geode-core/src/main/java/com/gemstone/gemfire/management/MemberMXBean.java 
> 5f656a935883897d20c1b650c04ef12357c66413 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  cdbd3db5983fdb67221125a9e14e5cb2d69a6870 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/DataCommands.java
>  c1c04a31b73732511531bbfda1f4c9c58dc5624f 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/RegionCommands.java
>  ac69d32a3061e8857c94de6577731ee5e572b2ac 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/remote/CommandProcessor.java
>  87053ccecf155a40a1528715119da4d0c29a85fd 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/AccessControlMBean.java
>  992153842e325c3ab228ff7642ff614185392f6b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/MBeanServerWrapper.java
>  bbc044239f6cae631d3b15b2d61de4ef21743a7a 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/ResourceOperation.java
>  f72a83524332ad33aa1e2a91b5aa5072c9b721ff 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/ResourceOperationContext.java
>  396cdace6dc7dc633db71c72e72bce14b94263b7 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/AbstractCommandsController.java
>  211d0b1b785807e6046f6b9a8fe35121379ac595 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/support/EnvironmentVariablesHandlerInterceptor.java
>  bb7a27d4c6639e20f0f41e2c594a30632338ad25 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/shell/RestHttpOperationInvoker.java
>  439e2b4397cf82df172a257faf1469e1984d5a57 
>   geode-core/src/main/java/com/gemstone/gemfire/security/CustomAuthRealm.java 
> 76fc8521772c5cf073dd23dae607b1ab818e3014 
>   
> geode-core/src/main/java/com/gemstone/gemfire/security/JMXShiroAuthenticator.java
>  8f86c38b4fd377082305c14756b8772c71abc9e4 
>   geode-core/src/main/java/com/gemstone/gemfire/security/ShiroUtil.java 
> 01914e42f56b89552f23ef8801139e5288de377e 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/FixedPRSinglehopDUnitTest.java
>  61ea97a7112de029232a97eb997830392445b599 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/CacheServerMBeanAuthorizationJUnitTest.java
>  baa8393bff6989145d14c5a9808c0fa53e8b8a9c 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/CacheServerMBeanShiroJUnitTest.java
>  e55623d4103367c095ea82303ba172adc71c8b2b 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/CliCommandsSecurityTest.java
>  5e49f9270bd67f1468f87a57b9bfafa719816982 
>   
>

Re: Review Request 46844: GEODE-1323: Extend PerTestClassLoaderRunner to work with Rules


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


Ship it!




Ship It!

- Kirk Lund


On April 29, 2016, 4:37 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46844/
> ---
> 
> (Updated April 29, 2016, 4:37 p.m.)
> 
> 
> Review request for geode, Jinmei Liao and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1323: Extend PerTestClassLoaderRunner to work with Rules
> 
> 
> Diffs
> -
> 
>   
> extensions/geode-modules-session/src/test/java/com/gemstone/gemfire/modules/session/junit/PerTestClassLoaderRunner.java
>  3e5c9988871d0994f3394bbf5d85e8d0568f983c 
> 
> Diff: https://reviews.apache.org/r/46844/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Re: Review Request 46837: Additional GEODE-17 review: enhance the GeodeSecurityUtil and review changes


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




geode-core/src/main/java/com/gemstone/gemfire/security/ShiroUtil.java (line 18)


I still want to see this moved to "package 
com.gemstone.gemfire.internal.security;"

com.gemstone.gemfire.security sets a precedent for backwards compatibility 
and essentially ties us permanently to this as a customer API.

It also has a quality certification impact which basically says we expect 
the users to use this API and we certify that we've tested it in everyway that 
the user might use it.


- Kirk Lund


On April 29, 2016, 3:34 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46837/
> ---
> 
> (Updated April 29, 2016, 3:34 p.m.)
> 
> 
> Review request for geode, Jens Deppe and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Merge branch 'develop' into feature/GEODE-17-2
> 
> 
> GEODE-17: enhance the GeodeSecurityUtil and review changes
> 
> * allow operations that does not require any authorizations
> * put/get, import/export and locate entry will check region access
> * rename EnvronmentVariablesHandlerInterceptor
> * rename ShiroUtil to GeodeSecurityUtil
> * reformat code and review changes
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/OperationContext.java
>  dd290c5d6b67738b24872b29f4ad08cac7944bc9 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/DistributedSystemMXBean.java
>  a27d92f96b083f700cf0dc356c9c522f737bc861 
>   geode-core/src/main/java/com/gemstone/gemfire/management/MemberMXBean.java 
> 5f656a935883897d20c1b650c04ef12357c66413 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  cdbd3db5983fdb67221125a9e14e5cb2d69a6870 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/DataCommands.java
>  c1c04a31b73732511531bbfda1f4c9c58dc5624f 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/RegionCommands.java
>  ac69d32a3061e8857c94de6577731ee5e572b2ac 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/remote/CommandProcessor.java
>  87053ccecf155a40a1528715119da4d0c29a85fd 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/AccessControlMBean.java
>  992153842e325c3ab228ff7642ff614185392f6b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/MBeanServerWrapper.java
>  bbc044239f6cae631d3b15b2d61de4ef21743a7a 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/ResourceOperation.java
>  f72a83524332ad33aa1e2a91b5aa5072c9b721ff 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/ResourceOperationContext.java
>  396cdace6dc7dc633db71c72e72bce14b94263b7 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/AbstractCommandsController.java
>  211d0b1b785807e6046f6b9a8fe35121379ac595 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/support/EnvironmentVariablesHandlerInterceptor.java
>  bb7a27d4c6639e20f0f41e2c594a30632338ad25 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/shell/RestHttpOperationInvoker.java
>  439e2b4397cf82df172a257faf1469e1984d5a57 
>   geode-core/src/main/java/com/gemstone/gemfire/security/CustomAuthRealm.java 
> 76fc8521772c5cf073dd23dae607b1ab818e3014 
>   
> geode-core/src/main/java/com/gemstone/gemfire/security/JMXShiroAuthenticator.java
>  8f86c38b4fd377082305c14756b8772c71abc9e4 
>   geode-core/src/main/java/com/gemstone/gemfire/security/ShiroUtil.java 
> 01914e42f56b89552f23ef8801139e5288de377e 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/FixedPRSinglehopDUnitTest.java
>  61ea97a7112de029232a97eb997830392445b599 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/CacheServerMBeanAuthorizationJUnitTest.java
>  baa8393bff6989145d14c5a9808c0fa53e8b8a9c 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/CacheServerMBeanShiroJUnitTest.java
>  e55623d4103367c095ea82303ba172adc71c8b2b 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/CliCommandsSecurityTest.java
>  5e49f9270bd67f1468f87a57b9bfafa719816982 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/DataCommandsSecurityTest.java
>  7517f498bf4648a975b3e59b1736d3ba3203172f 
>   
>

Re: Review Request 46801: GEDOE-1321 GMSHealthMonitor: java.lang.IllegalStateException: Timer already cancelled

2016-04-29 Thread Jianxia Chen


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


Ship it!




Ship It!

- Jianxia Chen


On April 29, 2016, 4:47 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46801/
> ---
> 
> (Updated April 29, 2016, 4:47 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Jianxia Chen, and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Caught that exception.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/fd/GMSHealthMonitor.java
>  2d0f039 
> 
> Diff: https://reviews.apache.org/r/46801/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

Re: Review Request 46837: Additional GEODE-17 review: enhance the GeodeSecurityUtil and review changes


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


Ship it!




Ship It!

- Jens Deppe


On April 29, 2016, 3:34 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46837/
> ---
> 
> (Updated April 29, 2016, 3:34 p.m.)
> 
> 
> Review request for geode, Jens Deppe and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Merge branch 'develop' into feature/GEODE-17-2
> 
> 
> GEODE-17: enhance the GeodeSecurityUtil and review changes
> 
> * allow operations that does not require any authorizations
> * put/get, import/export and locate entry will check region access
> * rename EnvronmentVariablesHandlerInterceptor
> * rename ShiroUtil to GeodeSecurityUtil
> * reformat code and review changes
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/OperationContext.java
>  dd290c5d6b67738b24872b29f4ad08cac7944bc9 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/DistributedSystemMXBean.java
>  a27d92f96b083f700cf0dc356c9c522f737bc861 
>   geode-core/src/main/java/com/gemstone/gemfire/management/MemberMXBean.java 
> 5f656a935883897d20c1b650c04ef12357c66413 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  cdbd3db5983fdb67221125a9e14e5cb2d69a6870 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/DataCommands.java
>  c1c04a31b73732511531bbfda1f4c9c58dc5624f 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/RegionCommands.java
>  ac69d32a3061e8857c94de6577731ee5e572b2ac 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/remote/CommandProcessor.java
>  87053ccecf155a40a1528715119da4d0c29a85fd 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/AccessControlMBean.java
>  992153842e325c3ab228ff7642ff614185392f6b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/MBeanServerWrapper.java
>  bbc044239f6cae631d3b15b2d61de4ef21743a7a 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/ResourceOperation.java
>  f72a83524332ad33aa1e2a91b5aa5072c9b721ff 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/security/ResourceOperationContext.java
>  396cdace6dc7dc633db71c72e72bce14b94263b7 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/AbstractCommandsController.java
>  211d0b1b785807e6046f6b9a8fe35121379ac595 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/support/EnvironmentVariablesHandlerInterceptor.java
>  bb7a27d4c6639e20f0f41e2c594a30632338ad25 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/shell/RestHttpOperationInvoker.java
>  439e2b4397cf82df172a257faf1469e1984d5a57 
>   geode-core/src/main/java/com/gemstone/gemfire/security/CustomAuthRealm.java 
> 76fc8521772c5cf073dd23dae607b1ab818e3014 
>   
> geode-core/src/main/java/com/gemstone/gemfire/security/JMXShiroAuthenticator.java
>  8f86c38b4fd377082305c14756b8772c71abc9e4 
>   geode-core/src/main/java/com/gemstone/gemfire/security/ShiroUtil.java 
> 01914e42f56b89552f23ef8801139e5288de377e 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/FixedPRSinglehopDUnitTest.java
>  61ea97a7112de029232a97eb997830392445b599 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/CacheServerMBeanAuthorizationJUnitTest.java
>  baa8393bff6989145d14c5a9808c0fa53e8b8a9c 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/CacheServerMBeanShiroJUnitTest.java
>  e55623d4103367c095ea82303ba172adc71c8b2b 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/CliCommandsSecurityTest.java
>  5e49f9270bd67f1468f87a57b9bfafa719816982 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/DataCommandsSecurityTest.java
>  7517f498bf4648a975b3e59b1736d3ba3203172f 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/DiskStoreMXBeanSecurityJUnitTest.java
>  f2487367f6b8b7f747bdd641dc071acf57c2157f 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/GatewayReceiverMBeanSecurityTest.java
>  b28069f560d4ce68036a689444df2cd4733fa2d5 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/GatewaySenderMBeanSecurityTest.java
>  3a9412dab7f16595a02ac02d3e095525a5cc942b 
>   
>

Re: Review Request 46801: GEDOE-1321 GMSHealthMonitor: java.lang.IllegalStateException: Timer already cancelled

2016-04-29 Thread Bruce Schuchardt


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


Ship it!




Ship It!

- Bruce Schuchardt


On April 29, 2016, 4:47 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46801/
> ---
> 
> (Updated April 29, 2016, 4:47 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Jianxia Chen, and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Caught that exception.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/fd/GMSHealthMonitor.java
>  2d0f039 
> 
> Diff: https://reviews.apache.org/r/46801/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

Re: Review Request 46801: GEDOE-1321 GMSHealthMonitor: java.lang.IllegalStateException: Timer already cancelled


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

(Updated April 29, 2016, 4:47 p.m.)


Review request for geode, Bruce Schuchardt, Jianxia Chen, and Udo Kohlmeyer.


Changes
---

Updated patch again


Repository: geode


Description
---

Caught that exception.


Diffs (updated)
-

  
geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/fd/GMSHealthMonitor.java
 2d0f039 

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


Testing
---


Thanks,

Hitesh Khamesra

Re: Review Request 46844: GEODE-1323: Extend PerTestClassLoaderRunner to work with Rules


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


Ship it!




Ship It!

- Jinmei Liao


On April 29, 2016, 4:37 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46844/
> ---
> 
> (Updated April 29, 2016, 4:37 p.m.)
> 
> 
> Review request for geode, Jinmei Liao and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1323: Extend PerTestClassLoaderRunner to work with Rules
> 
> 
> Diffs
> -
> 
>   
> extensions/geode-modules-session/src/test/java/com/gemstone/gemfire/modules/session/junit/PerTestClassLoaderRunner.java
>  3e5c9988871d0994f3394bbf5d85e8d0568f983c 
> 
> Diff: https://reviews.apache.org/r/46844/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Re: Review Request 46841: GEODE-1326: Add test for gfsh function execution with ResultCollector


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


Ship it!




Ship It!

- Jinmei Liao


On April 29, 2016, 4:23 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46841/
> ---
> 
> (Updated April 29, 2016, 4:23 p.m.)
> 
> 
> Review request for geode, Jinmei Liao and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1326: Add test for gfsh function execution with ResultCollector
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/FunctionCommandsDUnitTest.java
>  b4d4df1cb96f521b38a0554e2e31658558c6abda 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/ToUpperResultCollector.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46841/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Review Request 46844: GEODE-1323: Extend PerTestClassLoaderRunner to work with Rules


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

Review request for geode, Jinmei Liao and Kirk Lund.


Repository: geode


Description
---

GEODE-1323: Extend PerTestClassLoaderRunner to work with Rules


Diffs
-

  
extensions/geode-modules-session/src/test/java/com/gemstone/gemfire/modules/session/junit/PerTestClassLoaderRunner.java
 3e5c9988871d0994f3394bbf5d85e8d0568f983c 

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


Testing
---


Thanks,

Jens Deppe

Review Request 46843: GEODE-1324: Convert SessionReplicationIntegrationJUnitTest to use TemporaryFolder


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

Review request for geode, Jinmei Liao and Kirk Lund.


Repository: geode


Description
---

GEODE-1324: Convert SessionReplicationIntegrationJUnitTest to use 
TemporaryFolder


Diffs
-

  
extensions/geode-modules-session/src/test/java/com/gemstone/gemfire/modules/session/internal/filter/SessionReplicationIntegrationJUnitTest.java
 004f9fedd02c4ce496bcafae3fd1bbdef506a632 

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


Testing
---


Thanks,

Jens Deppe

Review Request 46841: GEODE-1326: Add test for gfsh function execution with ResultCollector


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

Review request for geode, Jinmei Liao and Kirk Lund.


Repository: geode


Description
---

GEODE-1326: Add test for gfsh function execution with ResultCollector


Diffs
-

  
geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/FunctionCommandsDUnitTest.java
 b4d4df1cb96f521b38a0554e2e31658558c6abda 
  
geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/ToUpperResultCollector.java
 PRE-CREATION 

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


Testing
---


Thanks,

Jens Deppe

Re: Review Request 46625: when there're multiple cache servers on the same jvm, keep the first proxy for the each client

2016-04-29 Thread xiaojian zhou


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

(Updated April 29, 2016, 4:04 p.m.)


Review request for geode and anilkumar gingade.


Changes
---

implemented review comments. 

add test for durable client.


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


Repository: geode


Description
---

Current API allows us to create 2 cache servers on the same JVM, then the client
will try to create 2 queues to that JVM, one secondary and one primary.
But the proxy is actually the same (since there's only one client), so the
CCN keeps destroying and recreating the proxy.

To fix, we will keep the first proxy and reject the duplicate creating.
Then the secondary proxy will automatically become primary.


Diffs (updated)
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/CacheClientNotifier.java
 1ba2294 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/CacheClientNotifierDUnitTest.java
 8bf819c 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/Simple2CacheServerDUnitTest.java
 PRE-CREATION 

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


Testing
---


Thanks,

xiaojian zhou

Re: Review Request 46705: Integrated Security for JMX and commands



> On April 28, 2016, 11:32 p.m., Kirk Lund wrote:
> > geode-pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/PulseAbstractTest.java,
> >  line 140
> > 
> >
> > hardcoded ports  and 8080 need to be replaced with random ports 
> > from AvailablePort until we have a better mechanism for random ports

uiTests are run mannually. Will fix this later.


> On April 28, 2016, 11:32 p.m., Kirk Lund wrote:
> > geode-pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/PulseAbstractTest.java,
> >  line 149
> > 
> >
> > we should be using Awaitility insted of Thread sleeps -- I suppose this 
> > test is old and came from GEODE-17

used awaitility to wait till jetty is started. There are many other calls of 
sleep in the tests later to wait till UI elements refreshes. This is just the 
nature of Selanium tests.


- Jinmei


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


On April 26, 2016, 4:20 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46705/
> ---
> 
> (Updated April 26, 2016, 4:20 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> integration security for JMX and commands
> *shiro security
> *Clean up resource and operation code for permission checking
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle e849b51 
>   
> geode-assembly/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommandsDUnitTest.java
>  b394063 
>   
> geode-assembly/src/test/java/com/gemstone/gemfire/management/internal/configuration/SharedConfigurationEndToEndDUnitTest.java
>  e1093a2 
>   geode-assembly/src/test/resources/expected_jars.txt 159d1e6 
>   geode-core/build.gradle 2206018 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/OperationContext.java
>  9482d6b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/AbstractDistributionConfig.java
>  c742005 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/ConfigAttribute.java
>  51712f9 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/ConfigAttributeChecker.java
>  14c1e54 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/ConfigAttributeDesc.java
>  57a4a72 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/ConfigAttributeGetter.java
>  678ecf0 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/ConfigAttributeSetter.java
>  ad8ad65 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/DistributionConfig.java
>  c1a96ea 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/DistributionConfigImpl.java
>  2f0e1d9 
>   geode-core/src/main/java/com/gemstone/gemfire/internal/AbstractConfig.java 
> 09fc61c 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/security/AuthorizeRequest.java
>  8e550d4 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/AsyncEventQueueMXBean.java
>  e96d78c 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/CacheServerMXBean.java
>  8255a93 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/DiskStoreMXBean.java 
> 79ff056 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/DistributedLockServiceMXBean.java
>  317ee33 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/DistributedRegionMXBean.java
>  3003827 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/DistributedSystemMXBean.java
>  a6f65d4 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/GatewayReceiverMXBean.java
>  519db6c 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/GatewaySenderMXBean.java
>  33c47a4 
>   geode-core/src/main/java/com/gemstone/gemfire/management/LocatorMXBean.java 
> ec4dd88 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/LockServiceMXBean.java
>  85a8e75 
>   geode-core/src/main/java/com/gemstone/gemfire/management/ManagerMXBean.java 
> 7272c8c 
>   geode-core/src/main/java/com/gemstone/gemfire/management/MemberMXBean.java 
> ed27569 
>   geode-core/src/main/java/com/gemstone/gemfire/management/RegionMXBean.java 
> 8c11d00 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/ManagementAgent.java
>  2547070 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/SystemManagementService.java
>  1de666c 
>   
>

Re: Review Request 46837: Additional GEODE-17 review: enhance the GeodeSecurityUtil and review changes