Re: Review Request 42883: GEODE-871: Frequent use of executeOnAllServers causes build-up of sockets in TIME_WAIT on locator machine

[Bruce Schuchardt]

> On Jan. 28, 2016, 1:04 a.m., Udo Kohlmeyer wrote:
> > The change in the TCPServer,
> > ```
> > DataSerializer.writeObject(response, output);
> > output.flush()
> > ```
> > seems a little redundant. As the writeObject internally already flushes the 
> > stream. Maybe test without the flush. But it cannot hurt to have a flush()

I wonder why DataSerializer.writeObject() is flushing the stream?  I wouldn't 
think we'd want it to do that.


- Bruce


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


On Jan. 28, 2016, 12:24 a.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42883/
> ---
> 
> (Updated Jan. 28, 2016, 12:24 a.m.)
> 
> 
> Review request for geode, Hitesh Khamesra and Udo Kohlmeyer.
> 
> 
> Bugs: GEODE-871
> https://issues.apache.org/jira/browse/GEODE-871
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This change-set alters the client to abort its TCP/IP connection to the 
> locator by enabling SO_LINGER and setting the timeout to zero before it 
> closes the connection.  The Locator closes its connection first, which puts 
> it into TIME_WAIT.  The client then aborts the connection, which cleans up 
> the Locator's TIME_WAIT connection.
> 
> 
> Diffs
> -
> 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/tcpserver/TcpClient.java
>  47f50b342e495a25978d86f717b6140b67687618 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/tcpserver/TcpServer.java
>  f52b9ab3a47c9dc4147a852695b789a2d11b958e 
> 
> Diff: https://reviews.apache.org/r/42883/diff/
> 
> 
> Testing
> ---
> 
> Manual testing using TcpClient to send GetAllServersRequests to the locator 
> thousands of times & counting the number of sockets open on the locator 
> machine with "netstat -a".
> 
> I'm not sure how this could be unit-tested.
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 42883: GEODE-871: Frequent use of executeOnAllServers causes build-up of sockets in TIME_WAIT on locator machine

[Udo Kohlmeyer]

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


Ship it!




The change in the TCPServer,
```
DataSerializer.writeObject(response, output);
output.flush()
```
seems a little redundant. As the writeObject internally already flushes the 
stream. Maybe test without the flush. But it cannot hurt to have a flush()

- Udo Kohlmeyer


On Jan. 28, 2016, 12:24 a.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42883/
> ---
> 
> (Updated Jan. 28, 2016, 12:24 a.m.)
> 
> 
> Review request for geode, Hitesh Khamesra and Udo Kohlmeyer.
> 
> 
> Bugs: GEODE-871
> https://issues.apache.org/jira/browse/GEODE-871
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This change-set alters the client to abort its TCP/IP connection to the 
> locator by enabling SO_LINGER and setting the timeout to zero before it 
> closes the connection.  The Locator closes its connection first, which puts 
> it into TIME_WAIT.  The client then aborts the connection, which cleans up 
> the Locator's TIME_WAIT connection.
> 
> 
> Diffs
> -
> 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/tcpserver/TcpClient.java
>  47f50b342e495a25978d86f717b6140b67687618 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/tcpserver/TcpServer.java
>  f52b9ab3a47c9dc4147a852695b789a2d11b958e 
> 
> Diff: https://reviews.apache.org/r/42883/diff/
> 
> 
> Testing
> ---
> 
> Manual testing using TcpClient to send GetAllServersRequests to the locator 
> thousands of times & counting the number of sockets open on the locator 
> machine with "netstat -a".
> 
> I'm not sure how this could be unit-tested.
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 42892: GEODE-873: Allowing for possible retry in testParallelPregationHA

[xiaojian zhou]

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


Ship it!




Ship It!

- xiaojian zhou


On Jan. 28, 2016, 1:47 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42892/
> ---
> 
> (Updated Jan. 28, 2016, 1:47 a.m.)
> 
> 
> Review request for geode, Barry Oglesby and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> It's possible a put could be retried due to the member shutdown in this
> test. If there is a retry, the stats may get incremented by one more
> event.
> 
> 
> Diffs
> -
> 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelWANStatsDUnitTest.java
>  4da0868da1d02008683ad1bbcec10f88f9ef77c2 
> 
> Diff: https://reviews.apache.org/r/42892/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Review Request 42886: GEODE-867: Ignore secondaries in waitForDispatcherToPause

[Dan Smith]

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

Review request for geode, Barry Oglesby and xiaojian zhou.


Repository: geode


Description
---

For serial gateways, secondary dispatchers are already paused in waiting
to become primary, so they don't flip the flag that indicates that the
dispatcher is paused.


Diffs
-

  
gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/AbstractGatewaySenderEventProcessor.java
 c19857f60e2ededbba52193352dbca1fe1e402ca 

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


Testing
---


Thanks,

Dan Smith

Re: Review Request 42889: GEODE-865: CI Failure: ConcurrentParallelGatewaySenderOperation_2_DUnitTest.testParallelGatewaySenders_SingleNode_UserPR_localDestroy_RecreateRegion

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Jan. 28, 2016, 1:37 a.m., Barry Oglesby wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42889/
> ---
> 
> (Updated Jan. 28, 2016, 1:37 a.m.)
> 
> 
> Review request for geode, Dan Smith and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-865: 
> ConcurrentParallelGatewaySenderOperation_2_DUnitTest.testParallelGatewaySenders_SingleNode_UserPR_localDestroy_RecreateRegion
> 
> - add lambda support (mostly but not completely done)
> - refactored similar behavior out into local methods
> 
> 
> Diffs
> -
> 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/WANTestBase.java
>  230c8d8ce6f903cf5e4b9c8bf42b87ca04271647 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/concurrent/ConcurrentParallelGatewaySenderOperation_2_DUnitTest.java
>  f770062e2a2fdb8c9d35cd2d4f76ac96fa56ac37 
> 
> Diff: https://reviews.apache.org/r/42889/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Barry Oglesby
> 
>

Re: Review Request 42889: GEODE-865: CI Failure: ConcurrentParallelGatewaySenderOperation_2_DUnitTest.testParallelGatewaySenders_SingleNode_UserPR_localDestroy_RecreateRegion

[xiaojian zhou]

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




gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/concurrent/ConcurrentParallelGatewaySenderOperation_2_DUnitTest.java
 (line 526)


I have been thinking of make this method more generic to be shared by all 
the WAN test cases and AEQ test cases. 

Others look good.


- xiaojian zhou


On Jan. 28, 2016, 1:37 a.m., Barry Oglesby wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42889/
> ---
> 
> (Updated Jan. 28, 2016, 1:37 a.m.)
> 
> 
> Review request for geode, Dan Smith and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-865: 
> ConcurrentParallelGatewaySenderOperation_2_DUnitTest.testParallelGatewaySenders_SingleNode_UserPR_localDestroy_RecreateRegion
> 
> - add lambda support (mostly but not completely done)
> - refactored similar behavior out into local methods
> 
> 
> Diffs
> -
> 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/WANTestBase.java
>  230c8d8ce6f903cf5e4b9c8bf42b87ca04271647 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/concurrent/ConcurrentParallelGatewaySenderOperation_2_DUnitTest.java
>  f770062e2a2fdb8c9d35cd2d4f76ac96fa56ac37 
> 
> Diff: https://reviews.apache.org/r/42889/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Barry Oglesby
> 
>

Review Request 42892: GEODE-873: Allowing for possible retry in testParallelPregationHA

[Dan Smith]

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

Review request for geode, Barry Oglesby and xiaojian zhou.


Repository: geode


Description
---

It's possible a put could be retried due to the member shutdown in this
test. If there is a retry, the stats may get incremented by one more
event.


Diffs
-

  
gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelWANStatsDUnitTest.java
 4da0868da1d02008683ad1bbcec10f88f9ef77c2 

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


Testing
---


Thanks,

Dan Smith

Re: Geode versions in Jira tickets

[Anthony Baker]

To follow up on this:  there is now a 1.0.0-incubating.M2 version tag in JIRA.

Here’s what I recommend:

1) 1.0.0-incubating.M1

Don’t use this tag unless you’re making changes on the 
release/1.0.0-incubating.M1 branch.

2) 1.0.0-incubating.M2

Use this tag when a fix has been merged to develop.

3) 1.0.0-incubating

I think this tag is confusing and probably shouldn’t be used until our “next” 
release is going to be 1.0.0-incubating.  Since we don’t currently have 
parallel release versions (let’s be linear!) we should only be setting a single 
value in the “Fixed version” field.

Anthony

> On Jan 20, 2016, at 10:30 AM, Dan Smith  wrote:
> 
> One question on that is do we fill in the fix version at the time the bug
> is fixed, or when the release is made? For example right now we're making
> fixes that will probably be in a .M2 release, but there is no .M2 in JIRA
> yet.
> 
> -Dan
> 
> On Wed, Jan 20, 2016 at 10:22 AM, John Blum  wrote:
> 
>> With Spring projects, we use "affects" version that an issue was reported
>> in (though with Geode not having an official release yet, hmmm).  The fix
>> (or target) version is the version that the fix will be released in.
>> 
>> On Wed, Jan 20, 2016 at 8:58 AM, Kirk Lund  wrote:
>> 
>>> Darrel and I were just discussing and wondering: What's the current
>>> guidelines for the Geode versions that should be specified in the Affects
>>> Versions and Fix Versions of Jira tickets? It's still not clear to me.
>>> 
>>> -Kirk
>>> 
>> 
>> 
>> 
>> --
>> -John
>> 503-504-8657
>> john.blum10101 (skype)
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Geode versions in Jira tickets

[Nitin Lamba]

+1

To avoid the confusion, does it make sense to just delete this tag? Or perhaps 
rename/ reuse it to 1.1.0-incubating.M1 for the next feature release? 

We're in a bit of a clean-up mode right now so even though WAN, CQ and Pulse 
are big feature additions, we're still cleaning-up contributed code within 
Geode. So these may be in 1.0.0-incubating.M2 scope instead of 1.1.0. We can 
decide on this after the first (M1) release is blessed.

For now, I've also cleaned-up the wiki pages to accurately capture the release 
activities till date and created a separate page for the second milestone (M2) 
release [1].

Thanks,
Nitin
[1] 
https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release

From: Anthony Baker 
Sent: Wednesday, January 27, 2016 2:46 PM
To: dev@geode.incubator.apache.org
Subject: Re: Geode versions in Jira tickets

To follow up on this:  there is now a 1.0.0-incubating.M2 version tag in JIRA.

Here’s what I recommend:

1) 1.0.0-incubating.M1

Don’t use this tag unless you’re making changes on the 
release/1.0.0-incubating.M1 branch.

2) 1.0.0-incubating.M2

Use this tag when a fix has been merged to develop.

3) 1.0.0-incubating

I think this tag is confusing and probably shouldn’t be used until our “next” 
release is going to be 1.0.0-incubating.  Since we don’t currently have 
parallel release versions (let’s be linear!) we should only be setting a single 
value in the “Fixed version” field.

Anthony

> On Jan 20, 2016, at 10:30 AM, Dan Smith  wrote:
>
> One question on that is do we fill in the fix version at the time the bug
> is fixed, or when the release is made? For example right now we're making
> fixes that will probably be in a .M2 release, but there is no .M2 in JIRA
> yet.
>
> -Dan
>
> On Wed, Jan 20, 2016 at 10:22 AM, John Blum  wrote:
>
>> With Spring projects, we use "affects" version that an issue was reported
>> in (though with Geode not having an official release yet, hmmm).  The fix
>> (or target) version is the version that the fix will be released in.
>>
>> On Wed, Jan 20, 2016 at 8:58 AM, Kirk Lund  wrote:
>>
>>> Darrel and I were just discussing and wondering: What's the current
>>> guidelines for the Geode versions that should be specified in the Affects
>>> Versions and Fix Versions of Jira tickets? It's still not clear to me.
>>>
>>> -Kirk
>>>
>>
>>
>>
>> --
>> -John
>> 503-504-8657
>> john.blum10101 (skype)
>>

Re: Review Request 42886: GEODE-867: Ignore secondaries in waitForDispatcherToPause

[xiaojian zhou]

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


Ship it!




Ship It!

- xiaojian zhou


On Jan. 28, 2016, 12:46 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42886/
> ---
> 
> (Updated Jan. 28, 2016, 12:46 a.m.)
> 
> 
> Review request for geode, Barry Oglesby and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> For serial gateways, secondary dispatchers are already paused in waiting
> to become primary, so they don't flip the flag that indicates that the
> dispatcher is paused.
> 
> 
> Diffs
> -
> 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/AbstractGatewaySenderEventProcessor.java
>  c19857f60e2ededbba52193352dbca1fe1e402ca 
> 
> Diff: https://reviews.apache.org/r/42886/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 42883: GEODE-871: Frequent use of executeOnAllServers causes build-up of sockets in TIME_WAIT on locator machine

[Hitesh Khamesra]

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


Ship it!




Ship It!

- Hitesh Khamesra


On Jan. 28, 2016, 12:24 a.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42883/
> ---
> 
> (Updated Jan. 28, 2016, 12:24 a.m.)
> 
> 
> Review request for geode, Hitesh Khamesra and Udo Kohlmeyer.
> 
> 
> Bugs: GEODE-871
> https://issues.apache.org/jira/browse/GEODE-871
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This change-set alters the client to abort its TCP/IP connection to the 
> locator by enabling SO_LINGER and setting the timeout to zero before it 
> closes the connection.  The Locator closes its connection first, which puts 
> it into TIME_WAIT.  The client then aborts the connection, which cleans up 
> the Locator's TIME_WAIT connection.
> 
> 
> Diffs
> -
> 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/tcpserver/TcpClient.java
>  47f50b342e495a25978d86f717b6140b67687618 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/tcpserver/TcpServer.java
>  f52b9ab3a47c9dc4147a852695b789a2d11b958e 
> 
> Diff: https://reviews.apache.org/r/42883/diff/
> 
> 
> Testing
> ---
> 
> Manual testing using TcpClient to send GetAllServersRequests to the locator 
> thousands of times & counting the number of sockets open on the locator 
> machine with "netstat -a".
> 
> I'm not sure how this could be unit-tested.
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 42885: GEODE-872: Removing duplicate code from ConcurrentSerialGatewaySenderOperationsDUnitTest

[xiaojian zhou]

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


Ship it!




Ship It!

- xiaojian zhou


On Jan. 28, 2016, 12:43 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42885/
> ---
> 
> (Updated Jan. 28, 2016, 12:43 a.m.)
> 
> 
> Review request for geode, Barry Oglesby and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This test was almost an exact copy of
> SerialGatewaySenderOperationsDUnitTest, with a few lines changes. The
> non concurrent test had already fixed the suspect string, but the
> concurrent test did not. By throwing away the code from Concurrent* and
> making it extend the non-concurrent test, this bug is fixed.
> 
> The test has also been tuned to do fewer operations and take less time.
> 
> 
> Diffs
> -
> 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/WANTestBase.java
>  0c32d1fee204544cae490da9c048713c65fe6d29 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/concurrent/ConcurrentSerialGatewaySenderOperationsDUnitTest.java
>  b709334f7272cf50498e4d4ce910434691652343 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialGatewaySenderOperationsDUnitTest.java
>  d30289b7ed2130b25be6b865f3516b466e28a820 
> 
> Diff: https://reviews.apache.org/r/42885/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 42889: GEODE-865: CI Failure: ConcurrentParallelGatewaySenderOperation_2_DUnitTest.testParallelGatewaySenders_SingleNode_UserPR_localDestroy_RecreateRegion

[Barry Oglesby]

> On Jan. 28, 2016, 1:46 a.m., xiaojian zhou wrote:
> > gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/concurrent/ConcurrentParallelGatewaySenderOperation_2_DUnitTest.java,
> >  line 981
> > 
> >
> > I have been thinking of make this method more generic to be shared by 
> > all the WAN test cases and AEQ test cases. 
> > 
> > Others look good.

This bit of code was repeated in 12 tests in this file and probably a bunch of 
times in other files too. I'll move it up to WANTestBase.


- Barry


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


On Jan. 28, 2016, 1:37 a.m., Barry Oglesby wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42889/
> ---
> 
> (Updated Jan. 28, 2016, 1:37 a.m.)
> 
> 
> Review request for geode, Dan Smith and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-865: 
> ConcurrentParallelGatewaySenderOperation_2_DUnitTest.testParallelGatewaySenders_SingleNode_UserPR_localDestroy_RecreateRegion
> 
> - add lambda support (mostly but not completely done)
> - refactored similar behavior out into local methods
> 
> 
> Diffs
> -
> 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/WANTestBase.java
>  230c8d8ce6f903cf5e4b9c8bf42b87ca04271647 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/concurrent/ConcurrentParallelGatewaySenderOperation_2_DUnitTest.java
>  f770062e2a2fdb8c9d35cd2d4f76ac96fa56ac37 
> 
> Diff: https://reviews.apache.org/r/42889/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Barry Oglesby
> 
>

Re: Review Request 42892: GEODE-873: Allowing for possible retry in testParallelPregationHA

[Barry Oglesby]

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


Ship it!




Ship It!

- Barry Oglesby


On Jan. 28, 2016, 1:47 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42892/
> ---
> 
> (Updated Jan. 28, 2016, 1:47 a.m.)
> 
> 
> Review request for geode, Barry Oglesby and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> It's possible a put could be retried due to the member shutdown in this
> test. If there is a retry, the stats may get incremented by one more
> event.
> 
> 
> Diffs
> -
> 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelWANStatsDUnitTest.java
>  4da0868da1d02008683ad1bbcec10f88f9ef77c2 
> 
> Diff: https://reviews.apache.org/r/42892/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 42885: GEODE-872: Removing duplicate code from ConcurrentSerialGatewaySenderOperationsDUnitTest

[Barry Oglesby]

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


Ship it!




Ship It!

- Barry Oglesby


On Jan. 28, 2016, 12:43 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42885/
> ---
> 
> (Updated Jan. 28, 2016, 12:43 a.m.)
> 
> 
> Review request for geode, Barry Oglesby and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This test was almost an exact copy of
> SerialGatewaySenderOperationsDUnitTest, with a few lines changes. The
> non concurrent test had already fixed the suspect string, but the
> concurrent test did not. By throwing away the code from Concurrent* and
> making it extend the non-concurrent test, this bug is fixed.
> 
> The test has also been tuned to do fewer operations and take less time.
> 
> 
> Diffs
> -
> 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/WANTestBase.java
>  0c32d1fee204544cae490da9c048713c65fe6d29 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/concurrent/ConcurrentSerialGatewaySenderOperationsDUnitTest.java
>  b709334f7272cf50498e4d4ce910434691652343 
>   
> gemfire-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialGatewaySenderOperationsDUnitTest.java
>  d30289b7ed2130b25be6b865f3516b466e28a820 
> 
> Diff: https://reviews.apache.org/r/42885/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 42886: GEODE-867: Ignore secondaries in waitForDispatcherToPause

[Barry Oglesby]

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


Ship it!




Ship It!

- Barry Oglesby


On Jan. 28, 2016, 12:46 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42886/
> ---
> 
> (Updated Jan. 28, 2016, 12:46 a.m.)
> 
> 
> Review request for geode, Barry Oglesby and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> For serial gateways, secondary dispatchers are already paused in waiting
> to become primary, so they don't flip the flag that indicates that the
> dispatcher is paused.
> 
> 
> Diffs
> -
> 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/AbstractGatewaySenderEventProcessor.java
>  c19857f60e2ededbba52193352dbca1fe1e402ca 
> 
> Diff: https://reviews.apache.org/r/42886/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #203 was successful.
---
Scheduled
1226 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Review Request 42883: GEODE-871: Frequent use of executeOnAllServers causes build-up of sockets in TIME_WAIT on locator machine

[Bruce Schuchardt]

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

Review request for geode, Hitesh Khamesra and Udo Kohlmeyer.


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


Repository: geode


Description
---

This change-set alters the client to abort its TCP/IP connection to the locator 
by enabling SO_LINGER and setting the timeout to zero before it closes the 
connection.  The Locator closes its connection first, which puts it into 
TIME_WAIT.  The client then aborts the connection, which cleans up the 
Locator's TIME_WAIT connection.


Diffs
-

  
gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/tcpserver/TcpClient.java
 47f50b342e495a25978d86f717b6140b67687618 
  
gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/tcpserver/TcpServer.java
 f52b9ab3a47c9dc4147a852695b789a2d11b958e 

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


Testing
---

Manual testing using TcpClient to send GetAllServersRequests to the locator 
thousands of times & counting the number of sockets open on the locator machine 
with "netstat -a".

I'm not sure how this could be unit-tested.


Thanks,

Bruce Schuchardt

[GitHub] incubator-geode pull request: GEODE-852: refactor gemfire-pulse no...

[jinmeiliao]

GitHub user jinmeiliao opened a pull request:

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

GEODE-852: refactor gemfire-pulse not to generate a pulseverion.prope…

…rties file but copy it from gemfire-core

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

$ git pull https://github.com/jinmeiliao/incubator-geode feature/GEODE-852

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

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

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

This closes #80


commit a1b922c97e076553c95693d5e4cf223df9be4bfb
Author: Jinmei Liao 
Date:   2016-01-27T17:18:35Z

GEODE-852: refactor gemfire-pulse not to generate a pulseverion.properties 
file but copy it from gemfire-core




---
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: Proposal: Move Events to a non-Repo website

[Dave Barnes]

If we choose to proceed in this direction, we'll need a
community-accessible site that hosts a public Google calendar. Does this
already exist, or do we need to create one?


On Tue, Jan 26, 2016 at 10:28 PM, William Markito 
wrote:

> The javascript integration you did looks really good to me...  Although the
> Brazilian calendar might be too much given the number of holidays... :P
>
> A separate website would be a bit confusing since it would not be handled
> or managed within the project or by committers of the project, which might
> be a similar problem for a google calendar but might more doable...
>
> About your second question the calendar widget would take of it once the
> events pass.  For now, I'm not sure we need to be much concerned since it's
> also good for people to see events that already happened so they can find
> content...
>
> Just my 2 cents.
>
> On Tue, Jan 26, 2016 at 5:13 PM Dave Barnes  wrote:
>
> > This was a proof-of-concept, but the redesign needs more thought. I
> think a
> > separate site will allow more flexibility in presentation and design.
> >
> > I'm not sure how much information most publicly-visible Google calendars
> > provide, but this example's pretty slim. Doesn't begin to rival the
> > appearance or level of detail of the existing implementation.
> >
> > Those of us who care need to come up with a design. My first question has
> > to do with existing resources:
> > Is there a website already in existence that could serve as a host for
> > calendar postings from the community?
> >
> > Second question: In the meantime, how shall we handle updates to the
> > existing site? The Jan 31 event will go 'stale' in less than a week.
> >
> > On Tue, Jan 26, 2016 at 4:47 PM, Dan Smith  wrote:
> >
> > > +1 Good idea!
> > >
> > > -Dan
> > >
> > > On Tue, Jan 26, 2016 at 3:44 PM, Greg Chase 
> wrote:
> > >
> > > > +1 for supporting Brazilian Holidays
> > > >
> > > > +1 for a calendar service that makes it easier for the community to
> > > > contribute events.
> > > >
> > > > On Tue, Jan 26, 2016 at 3:26 PM, Dave Barnes 
> > wrote:
> > > >
> > > > > First pass, using the calendar of Brazilian Holidays - look just
> > below
> > > > the
> > > > > Pivotal events:
> > > > >
> > > > >
> http://ec2-52-33-216-127.us-west-2.compute.amazonaws.com/community/
> > > > >
> > > > > On Tue, Jan 26, 2016 at 7:43 AM, Nitin Lamba 
> > wrote:
> > > > >
> > > > > > +1 for data-driven event calendar! William's suggested solution
> is
> > > > > > available as a jQuery plugin [1].
> > > > > >
> > > > > > Nitin
> > > > > >
> > > > > > [1]
> > > > > >
> > > > >
> > > >
> > >
> >
> http://www.jqueryscript.net/social-media/jQuery-Plugin-To-Display-Google-Calendar-Feeds-On-Your-Website.html
> > > > > >
> > > > > > 
> > > > > > From: William Markito 
> > > > > > Sent: Tuesday, January 26, 2016 12:00 AM
> > > > > > To: dev@geode.incubator.apache.org
> > > > > > Subject: Re: Proposal: Move Events to a non-Repo website
> > > > > >
> > > > > > Hi Dave,  I think it's a great idea!  In fact, I'd rather have it
> > > some
> > > > > how
> > > > > > (javascript ?) pull that data from a Google Calendar feed or
> > > something
> > > > > like
> > > > > > that to automate the updates.
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > On Mon, Jan 25, 2016 at 4:34 PM Dave Barnes 
> > > > wrote:
> > > > > >
> > > > > > > RFF (Request for Feedback)
> > > > > > >
> > > > > > > Apache Geode website design suggestion: Replace the volatile
> > Events
> > > > > > section
> > > > > > > of the Geode website with a link to a community events site
> > that's
> > > > not
> > > > > > part
> > > > > > > of the Apache Geode source code repo. That way, the events can
> be
> > > > > updated
> > > > > > > quickly by community members without the delay, overhead, and
> > > > potential
> > > > > > > code corruption resulting from updating calendar items in the
> > code
> > > > > repo.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Proposal: Move Events to a non-Repo website

[Dave Barnes]

This question (does the external site idea play well with our community
policies?) is an important one. My proposal comes from efficiency
considerations - let's hear from the community: if consensus is that the
proposal conflicts with policy, I'll certainly withdraw it.
-Dave

On Wed, Jan 27, 2016 at 9:57 AM, Anthony Baker  wrote:

> Is hosting the data on a site external to ASF infrastructure in accord
> with our community policies?
>
> Anthony
>
> > On Jan 27, 2016, at 9:44 AM, Gregory Chase  wrote:
> >
> > Pivotal Data Communities maintains this public calendar:
> >
> https://calendar.google.com/calendar/embed?src=pivotal.io_u8kgvuahjkboh1gnfhv5ts2v9c%40group.calendar.google.com=America/Los_Angeles
> >
> > However not sure we can sort out the Geode events.
> >
> > We can create an additional calendar to host on behalf of Apache Geode,
> as
> > much as I don't like double entry :)
> >
> > -Greg
> >
> > On Wed, Jan 27, 2016 at 9:40 AM, Dave Barnes  wrote:
> >
> >> If we choose to proceed in this direction, we'll need a
> >> community-accessible site that hosts a public Google calendar. Does this
> >> already exist, or do we need to create one?
> >>
> >>
> >> On Tue, Jan 26, 2016 at 10:28 PM, William Markito 
> >> wrote:
> >>
> >>> The javascript integration you did looks really good to me...  Although
> >> the
> >>> Brazilian calendar might be too much given the number of holidays... :P
> >>>
> >>> A separate website would be a bit confusing since it would not be
> handled
> >>> or managed within the project or by committers of the project, which
> >> might
> >>> be a similar problem for a google calendar but might more doable...
> >>>
> >>> About your second question the calendar widget would take of it once
> the
> >>> events pass.  For now, I'm not sure we need to be much concerned since
> >> it's
> >>> also good for people to see events that already happened so they can
> find
> >>> content...
> >>>
> >>> Just my 2 cents.
> >>>
> >>> On Tue, Jan 26, 2016 at 5:13 PM Dave Barnes 
> wrote:
> >>>
>  This was a proof-of-concept, but the redesign needs more thought. I
> >>> think a
>  separate site will allow more flexibility in presentation and design.
> 
>  I'm not sure how much information most publicly-visible Google
> >> calendars
>  provide, but this example's pretty slim. Doesn't begin to rival the
>  appearance or level of detail of the existing implementation.
> 
>  Those of us who care need to come up with a design. My first question
> >> has
>  to do with existing resources:
>  Is there a website already in existence that could serve as a host for
>  calendar postings from the community?
> 
>  Second question: In the meantime, how shall we handle updates to the
>  existing site? The Jan 31 event will go 'stale' in less than a week.
> 
>  On Tue, Jan 26, 2016 at 4:47 PM, Dan Smith  wrote:
> 
> > +1 Good idea!
> >
> > -Dan
> >
> > On Tue, Jan 26, 2016 at 3:44 PM, Greg Chase 
> >>> wrote:
> >
> >> +1 for supporting Brazilian Holidays
> >>
> >> +1 for a calendar service that makes it easier for the community to
> >> contribute events.
> >>
> >> On Tue, Jan 26, 2016 at 3:26 PM, Dave Barnes 
>  wrote:
> >>
> >>> First pass, using the calendar of Brazilian Holidays - look just
>  below
> >> the
> >>> Pivotal events:
> >>>
> >>>
> >>> http://ec2-52-33-216-127.us-west-2.compute.amazonaws.com/community/
> >>>
> >>> On Tue, Jan 26, 2016 at 7:43 AM, Nitin Lamba 
>  wrote:
> >>>
>  +1 for data-driven event calendar! William's suggested solution
> >>> is
>  available as a jQuery plugin [1].
> 
>  Nitin
> 
>  [1]
> 
> >>>
> >>
> >
> 
> >>>
> >>
> http://www.jqueryscript.net/social-media/jQuery-Plugin-To-Display-Google-Calendar-Feeds-On-Your-Website.html
> 
>  
>  From: William Markito 
>  Sent: Tuesday, January 26, 2016 12:00 AM
>  To: dev@geode.incubator.apache.org
>  Subject: Re: Proposal: Move Events to a non-Repo website
> 
>  Hi Dave,  I think it's a great idea!  In fact, I'd rather have
> >> it
> > some
> >>> how
>  (javascript ?) pull that data from a Google Calendar feed or
> > something
> >>> like
>  that to automate the updates.
> 
>  +1
> 
>  On Mon, Jan 25, 2016 at 4:34 PM Dave Barnes <
> >> dbar...@pivotal.io>
> >> wrote:
> 
> > RFF (Request for Feedback)
> >
> > Apache Geode website design suggestion: Replace the volatile
>  Events
>  section
> > of the 

Re: [GitHub] incubator-geode pull request: GEODE-852: refactor gemfire-pulse no...

[Kirk Lund]

I'll work on this PR.

-Kirk


On Wed, Jan 27, 2016 at 9:20 AM, jinmeiliao  wrote:

> GitHub user jinmeiliao opened a pull request:
>
> https://github.com/apache/incubator-geode/pull/80
>
> GEODE-852: refactor gemfire-pulse not to generate a pulseverion.prope…
>
> …rties file but copy it from gemfire-core
>
> You can merge this pull request into a Git repository by running:
>
> $ git pull https://github.com/jinmeiliao/incubator-geode
> feature/GEODE-852
>
> Alternatively you can review and apply these changes as the patch at:
>
> https://github.com/apache/incubator-geode/pull/80.patch
>
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
>
> This closes #80
>
> 
> commit a1b922c97e076553c95693d5e4cf223df9be4bfb
> Author: Jinmei Liao 
> Date:   2016-01-27T17:18:35Z
>
> GEODE-852: refactor gemfire-pulse not to generate a
> pulseverion.properties file but copy it from gemfire-core
>
> 
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>

[GitHub] incubator-geode pull request: GEODE-852: refactor gemfire-pulse no...

[jinmeiliao]

Github user jinmeiliao commented on the pull request:

https://github.com/apache/incubator-geode/pull/80#issuecomment-175766150
  
To avoid confusion, do not rename the properties file copied from 
gemfire-core


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

[GitHub] incubator-geode pull request: GEODE-852: refactor gemfire-pulse no...

[upthewaterspout]

Github user upthewaterspout commented on the pull request:

https://github.com/apache/incubator-geode/pull/80#issuecomment-175780734
  
Looks good! One minor point - I think this is missing something that will 
tell gradle what the copyPulsePropFile  task depends on. You could either add a 
dependsOn to the task, or maybe add an inputs.dir to the task:

inputs.dir project(':gemfire-core').sourceSets.main.output

Try running 
/gradlew  gemfire-pulse:copyPulsePropFile
or
/gradlew  gemfire-pulse:war

and you'll see what I mean; it won't generate the original properties file.


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

[GitHub] incubator-geode pull request: GEODE-852: refactor gemfire-pulse no...

[nitin-amp]

Github user nitin-amp commented on a diff in the pull request:

https://github.com/apache/incubator-geode/pull/80#discussion_r51018580
  
--- Diff: 
gemfire-pulse/src/main/java/com/vmware/gemfire/tools/pulse/internal/data/PulseConstants.java
 ---
@@ -38,7 +38,7 @@
 
   // Pulse version details properties from properties file
   public static final String PULSE_VERSION_PROPERTIES_FILE = 
"pulseversion.properties";
--- End diff --

Should this String change to 'GemFireVersion.properties'?


---
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: Proposal: Move Events to a non-Repo website

[Gregory Chase]

Pivotal Data Communities maintains this public calendar:
https://calendar.google.com/calendar/embed?src=pivotal.io_u8kgvuahjkboh1gnfhv5ts2v9c%40group.calendar.google.com=America/Los_Angeles

However not sure we can sort out the Geode events.

We can create an additional calendar to host on behalf of Apache Geode, as
much as I don't like double entry :)

-Greg

On Wed, Jan 27, 2016 at 9:40 AM, Dave Barnes  wrote:

> If we choose to proceed in this direction, we'll need a
> community-accessible site that hosts a public Google calendar. Does this
> already exist, or do we need to create one?
>
>
> On Tue, Jan 26, 2016 at 10:28 PM, William Markito 
> wrote:
>
> > The javascript integration you did looks really good to me...  Although
> the
> > Brazilian calendar might be too much given the number of holidays... :P
> >
> > A separate website would be a bit confusing since it would not be handled
> > or managed within the project or by committers of the project, which
> might
> > be a similar problem for a google calendar but might more doable...
> >
> > About your second question the calendar widget would take of it once the
> > events pass.  For now, I'm not sure we need to be much concerned since
> it's
> > also good for people to see events that already happened so they can find
> > content...
> >
> > Just my 2 cents.
> >
> > On Tue, Jan 26, 2016 at 5:13 PM Dave Barnes  wrote:
> >
> > > This was a proof-of-concept, but the redesign needs more thought. I
> > think a
> > > separate site will allow more flexibility in presentation and design.
> > >
> > > I'm not sure how much information most publicly-visible Google
> calendars
> > > provide, but this example's pretty slim. Doesn't begin to rival the
> > > appearance or level of detail of the existing implementation.
> > >
> > > Those of us who care need to come up with a design. My first question
> has
> > > to do with existing resources:
> > > Is there a website already in existence that could serve as a host for
> > > calendar postings from the community?
> > >
> > > Second question: In the meantime, how shall we handle updates to the
> > > existing site? The Jan 31 event will go 'stale' in less than a week.
> > >
> > > On Tue, Jan 26, 2016 at 4:47 PM, Dan Smith  wrote:
> > >
> > > > +1 Good idea!
> > > >
> > > > -Dan
> > > >
> > > > On Tue, Jan 26, 2016 at 3:44 PM, Greg Chase 
> > wrote:
> > > >
> > > > > +1 for supporting Brazilian Holidays
> > > > >
> > > > > +1 for a calendar service that makes it easier for the community to
> > > > > contribute events.
> > > > >
> > > > > On Tue, Jan 26, 2016 at 3:26 PM, Dave Barnes 
> > > wrote:
> > > > >
> > > > > > First pass, using the calendar of Brazilian Holidays - look just
> > > below
> > > > > the
> > > > > > Pivotal events:
> > > > > >
> > > > > >
> > http://ec2-52-33-216-127.us-west-2.compute.amazonaws.com/community/
> > > > > >
> > > > > > On Tue, Jan 26, 2016 at 7:43 AM, Nitin Lamba 
> > > wrote:
> > > > > >
> > > > > > > +1 for data-driven event calendar! William's suggested solution
> > is
> > > > > > > available as a jQuery plugin [1].
> > > > > > >
> > > > > > > Nitin
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://www.jqueryscript.net/social-media/jQuery-Plugin-To-Display-Google-Calendar-Feeds-On-Your-Website.html
> > > > > > >
> > > > > > > 
> > > > > > > From: William Markito 
> > > > > > > Sent: Tuesday, January 26, 2016 12:00 AM
> > > > > > > To: dev@geode.incubator.apache.org
> > > > > > > Subject: Re: Proposal: Move Events to a non-Repo website
> > > > > > >
> > > > > > > Hi Dave,  I think it's a great idea!  In fact, I'd rather have
> it
> > > > some
> > > > > > how
> > > > > > > (javascript ?) pull that data from a Google Calendar feed or
> > > > something
> > > > > > like
> > > > > > > that to automate the updates.
> > > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > On Mon, Jan 25, 2016 at 4:34 PM Dave Barnes <
> dbar...@pivotal.io>
> > > > > wrote:
> > > > > > >
> > > > > > > > RFF (Request for Feedback)
> > > > > > > >
> > > > > > > > Apache Geode website design suggestion: Replace the volatile
> > > Events
> > > > > > > section
> > > > > > > > of the Geode website with a link to a community events site
> > > that's
> > > > > not
> > > > > > > part
> > > > > > > > of the Apache Geode source code repo. That way, the events
> can
> > be
> > > > > > updated
> > > > > > > > quickly by community members without the delay, overhead, and
> > > > > potential
> > > > > > > > code corruption resulting from updating calendar items in the
> > > code
> > > > > > repo.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>



-- 
Greg Chase

Director of Big Data Communities
http://www.pivotal.io/big-data

Pivotal Software

Re: Proposal: Move Events to a non-Repo website

[Anthony Baker]

Is hosting the data on a site external to ASF infrastructure in accord with our 
community policies?

Anthony

> On Jan 27, 2016, at 9:44 AM, Gregory Chase  wrote:
> 
> Pivotal Data Communities maintains this public calendar:
> https://calendar.google.com/calendar/embed?src=pivotal.io_u8kgvuahjkboh1gnfhv5ts2v9c%40group.calendar.google.com=America/Los_Angeles
> 
> However not sure we can sort out the Geode events.
> 
> We can create an additional calendar to host on behalf of Apache Geode, as
> much as I don't like double entry :)
> 
> -Greg
> 
> On Wed, Jan 27, 2016 at 9:40 AM, Dave Barnes  wrote:
> 
>> If we choose to proceed in this direction, we'll need a
>> community-accessible site that hosts a public Google calendar. Does this
>> already exist, or do we need to create one?
>> 
>> 
>> On Tue, Jan 26, 2016 at 10:28 PM, William Markito 
>> wrote:
>> 
>>> The javascript integration you did looks really good to me...  Although
>> the
>>> Brazilian calendar might be too much given the number of holidays... :P
>>> 
>>> A separate website would be a bit confusing since it would not be handled
>>> or managed within the project or by committers of the project, which
>> might
>>> be a similar problem for a google calendar but might more doable...
>>> 
>>> About your second question the calendar widget would take of it once the
>>> events pass.  For now, I'm not sure we need to be much concerned since
>> it's
>>> also good for people to see events that already happened so they can find
>>> content...
>>> 
>>> Just my 2 cents.
>>> 
>>> On Tue, Jan 26, 2016 at 5:13 PM Dave Barnes  wrote:
>>> 
 This was a proof-of-concept, but the redesign needs more thought. I
>>> think a
 separate site will allow more flexibility in presentation and design.
 
 I'm not sure how much information most publicly-visible Google
>> calendars
 provide, but this example's pretty slim. Doesn't begin to rival the
 appearance or level of detail of the existing implementation.
 
 Those of us who care need to come up with a design. My first question
>> has
 to do with existing resources:
 Is there a website already in existence that could serve as a host for
 calendar postings from the community?
 
 Second question: In the meantime, how shall we handle updates to the
 existing site? The Jan 31 event will go 'stale' in less than a week.
 
 On Tue, Jan 26, 2016 at 4:47 PM, Dan Smith  wrote:
 
> +1 Good idea!
> 
> -Dan
> 
> On Tue, Jan 26, 2016 at 3:44 PM, Greg Chase 
>>> wrote:
> 
>> +1 for supporting Brazilian Holidays
>> 
>> +1 for a calendar service that makes it easier for the community to
>> contribute events.
>> 
>> On Tue, Jan 26, 2016 at 3:26 PM, Dave Barnes 
 wrote:
>> 
>>> First pass, using the calendar of Brazilian Holidays - look just
 below
>> the
>>> Pivotal events:
>>> 
>>> 
>>> http://ec2-52-33-216-127.us-west-2.compute.amazonaws.com/community/
>>> 
>>> On Tue, Jan 26, 2016 at 7:43 AM, Nitin Lamba 
 wrote:
>>> 
 +1 for data-driven event calendar! William's suggested solution
>>> is
 available as a jQuery plugin [1].
 
 Nitin
 
 [1]
 
>>> 
>> 
> 
 
>>> 
>> http://www.jqueryscript.net/social-media/jQuery-Plugin-To-Display-Google-Calendar-Feeds-On-Your-Website.html
 
 
 From: William Markito 
 Sent: Tuesday, January 26, 2016 12:00 AM
 To: dev@geode.incubator.apache.org
 Subject: Re: Proposal: Move Events to a non-Repo website
 
 Hi Dave,  I think it's a great idea!  In fact, I'd rather have
>> it
> some
>>> how
 (javascript ?) pull that data from a Google Calendar feed or
> something
>>> like
 that to automate the updates.
 
 +1
 
 On Mon, Jan 25, 2016 at 4:34 PM Dave Barnes <
>> dbar...@pivotal.io>
>> wrote:
 
> RFF (Request for Feedback)
> 
> Apache Geode website design suggestion: Replace the volatile
 Events
 section
> of the Geode website with a link to a community events site
 that's
>> not
 part
> of the Apache Geode source code repo. That way, the events
>> can
>>> be
>>> updated
> quickly by community members without the delay, overhead, and
>> potential
> code corruption resulting from updating calendar items in the
 code
>>> repo.
> 
 
>>> 
>> 
> 
 
>>> 
>> 
> 
> 
> 
> --
> Greg Chase
> 
> Director of Big Data Communities
> http://www.pivotal.io/big-data
> 
> Pivotal Software
> http://www.pivotal.io/
> 
> 

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

[Dan Smith]

Nitin's exactly right. Can someone with permissions on jenkins fix this?

We could also considering adding a pre build step that does a git clean. Eg

#This cleans all uncommitted files except for the gradle caches
git clean -dfx  -e /caches -e /.gradle -e /wrapper


On Wed, Jan 27, 2016 at 6:58 AM, Nitin Lamba  wrote:

> There was a bug that generated pulseVersion.properties file in the src
> tree. Dan has put in the fix yesterday and removed the rat ignore. However,
> seems the older generated file is still lying around - if you delete that
> file and clean the workspace, this issue should get fixed.
>
> Hope this helps,
> Nitin
>
> Sent from Outlook Mobile
>
>
>
>
> On Wed, Jan 27, 2016 at 5:37 AM -0800, "Anthony Baker"  > wrote:
>
>
> Unapproved licenses:
>
>
> /home/jenkins/jenkins-slave/workspace/Geode-nightly/gemfire-pulse/src/main/resources/pulseversion.properties
>
>
> On Jan 27, 2016, at 1:06 AM, Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
> See 
>
> Changes:
>
> [bschuchardt] GEODE-836: multicast state flush is broken
>
> [upthewaterspout] GEODE-854: Put pulseversion.properties in
> generated-resources
>
> [huynhja] GEODE-787: MemoryIndexStore needs unit tests
>
> [upthewaterspout] GEODE-857: Fixing synchronization in
> SystemFailure.stopWatchDog
>
> [upthewaterspout] GEODE-858: Remove 1 second sleep from
> InternalLocator.startTcpServer
>
> --
> [...truncated 522 lines...]
> at hydra.MethExecutor.executeObject(MethExecutor.java:267)
> at
> com.gemstone.gemfire.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:84)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$95(TCPTransport.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
>---
>Found suspect string in log4j at line 1996
>
>[error 2016/01/27 07:46:55.675 UTC  Connection(35)-67.195.81.148> tid=0xbd0] null
>javax.management.ListenerNotFoundException: Unknown listener
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.removeNotificationListener(DefaultMBeanServerInterceptor.java:1339)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.removeNotificationListener(DefaultMBeanServerInterceptor.java:1242)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.removeNotificationListener(JmxMBeanServer.java:870)
> at
> com.gemstone.gemfire.management.DistributedSystemDUnitTest$6.run(DistributedSystemDUnitTest.java:451)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at hydra.MethExecutor.executeObject(MethExecutor.java:267)
> at
> com.gemstone.gemfire.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:84)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
> 

[GitHub] incubator-geode pull request: GEODE-852: refactor gemfire-pulse no...

[jinmeiliao]

Github user jinmeiliao commented on the pull request:

https://github.com/apache/incubator-geode/pull/80#issuecomment-175786454
  
Good point. Will create another pull request for this


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

[GitHub] incubator-geode pull request: GEODE-852: refactor gemfire-pulse no...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] incubator-geode pull request: GEODE-852: copyPulsePropFile needs t...

[jinmeiliao]

GitHub user jinmeiliao opened a pull request:

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

GEODE-852: copyPulsePropFile needs to make sure gemfire-core builds f…

…irst

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

$ git pull https://github.com/jinmeiliao/incubator-geode feature/GEODE-852

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

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

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

This closes #81


commit 8c442733126989b38539fb300598131ca7db073e
Author: Jinmei Liao 
Date:   2016-01-27T18:45:47Z

GEODE-852: copyPulsePropFile needs to make sure gemfire-core builds first




---
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: Build failed in Jenkins: Geode-nightly #359

[Mark Bretl]

I have cleaned the Jenkins workspace, hope that will clean up the next
build.

--Mark

On Wed, Jan 27, 2016 at 9:55 AM, Dan Smith  wrote:

> Nitin's exactly right. Can someone with permissions on jenkins fix this?
>
> We could also considering adding a pre build step that does a git clean. Eg
>
> #This cleans all uncommitted files except for the gradle caches
> git clean -dfx  -e /caches -e /.gradle -e /wrapper
>
>
> On Wed, Jan 27, 2016 at 6:58 AM, Nitin Lamba  wrote:
>
> > There was a bug that generated pulseVersion.properties file in the src
> > tree. Dan has put in the fix yesterday and removed the rat ignore.
> However,
> > seems the older generated file is still lying around - if you delete that
> > file and clean the workspace, this issue should get fixed.
> >
> > Hope this helps,
> > Nitin
> >
> > Sent from Outlook Mobile
> >
> >
> >
> >
> > On Wed, Jan 27, 2016 at 5:37 AM -0800, "Anthony Baker" <
> aba...@pivotal.io
> > > wrote:
> >
> >
> > Unapproved licenses:
> >
> >
> >
> /home/jenkins/jenkins-slave/workspace/Geode-nightly/gemfire-pulse/src/main/resources/pulseversion.properties
> >
> >
> > On Jan 27, 2016, at 1:06 AM, Apache Jenkins Server <
> > jenk...@builds.apache.org> wrote:
> >
> > See 
> >
> > Changes:
> >
> > [bschuchardt] GEODE-836: multicast state flush is broken
> >
> > [upthewaterspout] GEODE-854: Put pulseversion.properties in
> > generated-resources
> >
> > [huynhja] GEODE-787: MemoryIndexStore needs unit tests
> >
> > [upthewaterspout] GEODE-857: Fixing synchronization in
> > SystemFailure.stopWatchDog
> >
> > [upthewaterspout] GEODE-858: Remove 1 second sleep from
> > InternalLocator.startTcpServer
> >
> > --
> > [...truncated 522 lines...]
> > at hydra.MethExecutor.executeObject(MethExecutor.java:267)
> > at
> >
> com.gemstone.gemfire.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:84)
> > at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:497)
> > at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
> > at sun.rmi.transport.Transport$1.run(Transport.java:200)
> > at sun.rmi.transport.Transport$1.run(Transport.java:197)
> > at java.security.AccessController.doPrivileged(Native Method)
> > at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> > at
> > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> > at
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> > at
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$95(TCPTransport.java:683)
> > at java.security.AccessController.doPrivileged(Native Method)
> > at
> >
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > at java.lang.Thread.run(Thread.java:745)
> >
> >
> ---
> >Found suspect string in log4j at line 1996
> >
> >[error 2016/01/27 07:46:55.675 UTC  > Connection(35)-67.195.81.148> tid=0xbd0] null
> >javax.management.ListenerNotFoundException: Unknown listener
> > at
> >
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.removeNotificationListener(DefaultMBeanServerInterceptor.java:1339)
> > at
> >
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.removeNotificationListener(DefaultMBeanServerInterceptor.java:1242)
> > at
> >
> com.sun.jmx.mbeanserver.JmxMBeanServer.removeNotificationListener(JmxMBeanServer.java:870)
> > at
> >
> com.gemstone.gemfire.management.DistributedSystemDUnitTest$6.run(DistributedSystemDUnitTest.java:451)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:497)
> > at hydra.MethExecutor.executeObject(MethExecutor.java:267)
> > at
> >
> com.gemstone.gemfire.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:84)
> > at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:497)
> > at
> 

Re: [VOTE] Apache Geode (Incubating) first Milestone release - v1.0.0-incubating.M1

[Anthony Baker]

For GEODE-610, I’ve committed updates as 
3bd930fd45bef7a15f6aa84268dcbf66ed6694a6 on develop.

I’ll work on spinning RC2 now.

Anthony

> On Jan 26, 2016, at 6:24 PM, Anthony Baker  wrote:
> 
> 
>> On Jan 26, 2016, at 2:55 PM, Niall Pemberton  
>> wrote:
>> 
>> Can the year on the copyright in both the source & binary NOTICE file also
>> be updated for RC2?
> 
> Yes we can!
> 
>> 
>> Theres no issue with distributing jopt-simple & JSON from a license PoV,
>> but policy on this is unclear to me. As a principle the ASF doesn't release
>> other people/project's code when they haven't donated it to the ASF, but at
>> the same time alot of releases contain files that were not donated. As a
>> good open source citizen, we should work with the jopt-simple project
>> rather than forking releasing their code. However, it seems fine to me that
>> its dealt with during incubation rather than specifically for this release.
>> 
> 
> Thanks for adding your perspective and FWIW I completely agree.
> 
>> So yes, the strategy outlined for RC2 makes sense to me.
>> 
>> Niall
>> 
> 
> So for spinning an RC2 we have the following changes to pull into the 
> release/1.0.0-incubating.M1 branch:
> 
> 1) Update instructions in README.md (GEODE-769)
> 
> commits:
>   2609946d8863d4e576820ac92d4318fd5f295b5a
>   9b74f89bbd64cc8a90cf256ad1af2466e21c6388
> 
> 2) Update copyright publication year in src/bin NOTICE files (GEODE-815)
> 
> commit:
>   80971d5250f7bc6fe3341d04c249cbee261dab0d
> 
> 3) Include Spring, Netty in binary NOTICE file (GEODE-610)
> 
> commit:
>   TBD…there’s still some discussion happening on this issue.  Comments 
> welcome!
> 
> Let’s try to wrap up the discussion on GEODE-610 so we can cut the RC 
> tomorrow.
> 
> Thanks,
> Anthony
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

RC2 is created

[Anthony Baker]

Here are the details:

Commit:
c26334542fa9e90daff5f58467d6e174b3e0f3e2

Tag:
rel/v1.0.0-incubating.M1.RC2

Signing key:
pub  4096R/C72CFB64 2015-10-01
Fingerprint=948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/incubator/geode/1.0.0-incubating.M1.RC2

Maven staging repository:
https://repository.apache.org/content/repositories/orgapachegeode-1001


Thanks to Swapnil for the help!

Anthony


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RC2 is created

[Roman Shaposhnik]

Great! Don't forget to restart a VOTE thread.

On Wed, Jan 27, 2016 at 11:41 AM, Anthony Baker  wrote:
> Here are the details:
>
> Commit:
> c26334542fa9e90daff5f58467d6e174b3e0f3e2
>
> Tag:
> rel/v1.0.0-incubating.M1.RC2
>
> Signing key:
> pub  4096R/C72CFB64 2015-10-01
> Fingerprint=948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64
>
> Source and binary distributions:
> https://dist.apache.org/repos/dist/dev/incubator/geode/1.0.0-incubating.M1.RC2
>
> Maven staging repository:
> https://repository.apache.org/content/repositories/orgapachegeode-1001
>
>
> Thanks to Swapnil for the help!
>
> Anthony

[VOTE] RC2: Apache Geode (Incubating) first Milestone release - v1.0.0-incubating.M1

[Nitin Lamba]

All,

This is the second release candidate of the first release for Apache Geode, 
version 1.0.0-incubating.M1. Thanks to all the community members to drive 
towards this milestone!

It fixes the following issues:
   
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12334248

Compared to first release candidate (RC1), it fixes the following issues:
[GEODE-610] - Review Geode's LICENSE & NOTICE File(s)
[GEODE-769] - improve README.md file
[GEODE-815] - RC Feedback: Fix LICENSE and NOTICE files

*** Please download, test and vote by Monday, February 01, 0800 hrs US Pacific.

Note that we are voting upon the source (tag):
   rel/1.0.0-incubating.M1.RC2
   
https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=tag;h=refs/tags/rel/v1.0.0-incubating.M1.RC2

Commit ID: c26334542fa9e90daff5f58467d6e174b3e0f3e2
   
https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=commit;h=c26334542fa9e90daff5f58467d6e174b3e0f3e2

Source and binary files:
   
https://dist.apache.org/repos/dist/dev/incubator/geode/1.0.0-incubating.M1.RC2/

For the first release, the documentation on how to install and use Apache Geode 
are hosted on pivotal.io:
   http://geode.docs.pivotal.io

Maven staging repo:
   https://repository.apache.org/content/repositories/orgapachegeode-1001/

Geode's KEYS file containing PGP keys we use to sign the release:
   
https://github.com/apache/incubator-geode/blob/release/1.0.0-incubating.M1/KEYS

Release Key: pub  4096R/C72CFB64 2015-10-01
Fingerprint: 948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64

Thanks,
Anthony & Nitin (on behalf of the Geode team)

Re: [VOTE] RC2: Apache Geode (Incubating) first Milestone release - v1.0.0-incubating.M1

[Nitin Lamba]

The link to source tag got messed-up. Correct link below:
https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=tag;h=refs/tags/rel/v1.0.0-incubating.M1.RC2

Thanks,
Nitin

From: Nitin Lamba 
Sent: Wednesday, January 27, 2016 12:21 PM
To: dev@geode.incubator.apache.org
Cc: Anthony Baker
Subject: [VOTE] RC2: Apache Geode (Incubating) first Milestone release - 
v1.0.0-incubating.M1

All,

This is the second release candidate of the first release for Apache Geode, 
version 1.0.0-incubating.M1. Thanks to all the community members to drive 
towards this milestone!

It fixes the following issues:
   
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12334248

Compared to first release candidate (RC1), it fixes the following issues:
[GEODE-610] - Review Geode's LICENSE & NOTICE File(s)
[GEODE-769] - improve README.md file
[GEODE-815] - RC Feedback: Fix LICENSE and NOTICE files

*** Please download, test and vote by Monday, February 01, 0800 hrs US Pacific.

Note that we are voting upon the source (tag):
   rel/1.0.0-incubating.M1.RC2
   
https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=tag;h=refs/tags/rel/v1.0.0-incubating.M1.RC2

Commit ID: c26334542fa9e90daff5f58467d6e174b3e0f3e2
   
https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=commit;h=c26334542fa9e90daff5f58467d6e174b3e0f3e2

Source and binary files:
   
https://dist.apache.org/repos/dist/dev/incubator/geode/1.0.0-incubating.M1.RC2/

For the first release, the documentation on how to install and use Apache Geode 
are hosted on pivotal.io:
   http://geode.docs.pivotal.io

Maven staging repo:
   https://repository.apache.org/content/repositories/orgapachegeode-1001/

Geode's KEYS file containing PGP keys we use to sign the release:
   
https://github.com/apache/incubator-geode/blob/release/1.0.0-incubating.M1/KEYS

Release Key: pub  4096R/C72CFB64 2015-10-01
Fingerprint: 948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64

Thanks,
Anthony & Nitin (on behalf of the Geode team)

Build failed in Jenkins: Geode-nightly #359

[Apache Jenkins Server]

See 

Changes:

[bschuchardt] GEODE-836: multicast state flush is broken

[upthewaterspout] GEODE-854: Put pulseversion.properties in generated-resources

[huynhja] GEODE-787: MemoryIndexStore needs unit tests

[upthewaterspout] GEODE-857: Fixing synchronization in 
SystemFailure.stopWatchDog

[upthewaterspout] GEODE-858: Remove 1 second sleep from 
InternalLocator.startTcpServer

--
[...truncated 522 lines...]
at hydra.MethExecutor.executeObject(MethExecutor.java:267)
at 
com.gemstone.gemfire.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:84)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$95(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

---
Found suspect string in log4j at line 1996

[error 2016/01/27 07:46:55.675 UTC  
tid=0xbd0] null
javax.management.ListenerNotFoundException: Unknown listener
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.removeNotificationListener(DefaultMBeanServerInterceptor.java:1339)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.removeNotificationListener(DefaultMBeanServerInterceptor.java:1242)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.removeNotificationListener(JmxMBeanServer.java:870)
at 
com.gemstone.gemfire.management.DistributedSystemDUnitTest$6.run(DistributedSystemDUnitTest.java:451)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at hydra.MethExecutor.executeObject(MethExecutor.java:267)
at 
com.gemstone.gemfire.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:84)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$95(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

---
Found suspect string in log4j at line 2025

[error 2016/01/27 07:46:55.675 UTC  
tid=0xbd0] null
javax.management.ListenerNotFoundException: Unknown listener
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.removeNotificationListener(DefaultMBeanServerInterceptor.java:1339)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.removeNotificationListener(DefaultMBeanServerInterceptor.java:1242)
at 

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

[Nitin Lamba]

There was a bug that generated pulseVersion.properties file in the src tree. 
Dan has put in the fix yesterday and removed the rat ignore. However, seems the 
older generated file is still lying around - if you delete that file and clean 
the workspace, this issue should get fixed.

Hope this helps,
Nitin

Sent from Outlook Mobile




On Wed, Jan 27, 2016 at 5:37 AM -0800, "Anthony Baker" 
> wrote:


Unapproved licenses:

  
/home/jenkins/jenkins-slave/workspace/Geode-nightly/gemfire-pulse/src/main/resources/pulseversion.properties


On Jan 27, 2016, at 1:06 AM, Apache Jenkins Server 
> wrote:

See 

Changes:

[bschuchardt] GEODE-836: multicast state flush is broken

[upthewaterspout] GEODE-854: Put pulseversion.properties in generated-resources

[huynhja] GEODE-787: MemoryIndexStore needs unit tests

[upthewaterspout] GEODE-857: Fixing synchronization in 
SystemFailure.stopWatchDog

[upthewaterspout] GEODE-858: Remove 1 second sleep from 
InternalLocator.startTcpServer

--
[...truncated 522 lines...]
at hydra.MethExecutor.executeObject(MethExecutor.java:267)
at 
com.gemstone.gemfire.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:84)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$95(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

   ---
   Found suspect string in log4j at line 1996

   [error 2016/01/27 07:46:55.675 UTC  
tid=0xbd0] null
   javax.management.ListenerNotFoundException: Unknown listener
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.removeNotificationListener(DefaultMBeanServerInterceptor.java:1339)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.removeNotificationListener(DefaultMBeanServerInterceptor.java:1242)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.removeNotificationListener(JmxMBeanServer.java:870)
at 
com.gemstone.gemfire.management.DistributedSystemDUnitTest$6.run(DistributedSystemDUnitTest.java:451)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at hydra.MethExecutor.executeObject(MethExecutor.java:267)
at 
com.gemstone.gemfire.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:84)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$95(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)