getSizeInBytes() return type

[Daniel Farcovich]

Hi,
We implement getSizeInBytes() in from Sizeable interface.
We have objects with size bigger than MAXINT, bigger than 2GB.
What is the impact of refactoring the code to return long instead of int? I 
mean except the technical aspect of changing the return types of the calling 
functions etc.
Which mechanisms / functionalities will be affected from this change, I know 
rebalancing will be affected for example.

Thanks,
Daniel Farcovich


This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

https://issues.apache.org/jira/browse/GEODE-3151

[Dinesh Akhand]

Hi  Team,

Please assign GEODE-3151 to me.

Can  anyone please review the pull request.

Thanks,
Dinesh Akhand

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

RE: Different member-timeout for particular jvm’s

[Aravind Musigumpula]

Hi,
May be I was not clear in my last mail. My question is that can we monitor a 
jvm based on it’s own member timeout instead of the member timeout of some 
other jvm(which is monitoring the this jvm).

Now if my view is [s1(coordinator), s2, s3, s4, s5] and member timeout for each 
member is different, the member s3 will suspect s4 on the basis of s3 member 
timeout and then final check will be done by coordinator member timeout. Every 
time the view changes, the order of monitoring also changes. So we cannot 
determine for how much time will a particular jvm will be removed from the view.

This can be solved if we use the member timeout of the jvm which is being 
monitored by the current member.

In the above view suppose s3 is monitoring s4. Now s3 marks s4 as suspect 
member on the basis of  s3 member timeout. Instead of this if s3 gets the 
member timeout of s4 and uses this new timeout to monitor s4, then we can 
determine for how much time a member will be removed from the view.

Is there any way to get the member timeout of one member from an another ?


Thanks,
Aravind Musigumpula

From: Aravind Musigumpula
Sent: Monday, July 03, 2017 9:35 PM
To: u...@geode.apache.org
Cc: bschucha...@pivotal.io
Subject: RE: Different member-timeout for particular jvm’s

Hi,

Can the member-timeout of a particular jvm can be used by the monitoring jvm.
Example: jvm1 monitors jvm2, jvm2 monitors jvm 3. Member timeout for jvm1 is 
10, jvm2 is 20 and jvm3 is 30. Suppose the jvm4 is coordinator and its member 
timeout is 30. So what if we want jvm1 should be monitored by other jvm’s for a 
deterministic time like 10 and jvm2 should be monitored for 20.

Right now, I understand that a jvm will be monitored by member timeout of the 
monitoring jvm and coordinator. My requirement is the each jvm should be 
monitored by its own member timeout followed by coordinator’s member-timeout.

In code there is a wait for a member timeout variable in GMSHealthMonitor.java.
if (pingResp.getResponseMsg() == null) {
pingResp.wait(memberTimeout);
  }

What if we get the member timeout of the jvm which is monitored by this one. We 
can do this in setNextNeighbor function in GMSHealthMonitor.java
But how to get the member-timeout of other jvm. Is it possible?

Thanks,
Aravind Musigumpula

From: Bruce Schuchardt [mailto:bschucha...@pivotal.io]
Sent: Tuesday, June 20, 2017 9:16 PM
To: u...@geode.apache.org
Subject: Re: Different member-timeout for particular jvm’s

It is the membership coordinator that performs the final check on a suspect 
member.  If you have network partition detection enabled or are using 
authentication of peers the role of membership coordinator will be a locator 
(if one is in the system) so in your scenario it will be the Locator that 
performs this check.  It will use its own member-timeout to determine how long 
to wait for a response to a "final check" message to the suspected member.

If the Locator is down then the oldest member in the system will take over the 
role.  This might be server1 if the membership view is [ s1, s2, s4, s3 ].  If 
there is a problem with s2 then s1 will use its own member-timeout setting to 
determine how long to wait for a final-check response from s1.

On 6/20/17 8:18 AM, Aravind Musigumpula wrote:
Hi,

Is there any way to configure different member-timeout for particular jvm’s.

According to my understanding each jvm monitors its neighbor. If any jvm is 
missing heart beat from its neighbor, it waits for member-timeout interval and 
sends a suspect message. Then Coordinator tries to contact that particular jvm, 
if it is unable to connect to that jvm. Coordinator waits for its configured 
member-timeout interval and removes that member if it is unable to connect to 
that jvm.

Scenario:
Locator: member-timeout=1
Server1: member-timeout=2
Server2: member-timeout=3
Server3: member-timeout=2
Server4: member-timeout=2

Suppose server1 is monitoring server2. I made server2 stuck. So server1 tries 
to contact the server2 , waits for 2ms and sends suspect message. Then 
locator tries to connect with server2 , if unable to connect waits for 1 
and removes server3 from view.

My requirement is I don’t want to kick server2 until 4ms. This can be done 
by setting 3 for the jvm which monitors server2. But how can we see that 
this particular jvm monitors server2. In my case every time different jvm is 
monitoring server2.
Please correct me if I am wrong.


Thanks,
Aravind Musigumpula

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herei

[GitHub] geode-native pull request #106: GEODE-2891 connect-timeout violation in C++ ...

[gregt5259]

GitHub user gregt5259 opened a pull request:

https://github.com/apache/geode-native/pull/106

GEODE-2891 connect-timeout violation in C++ Native Client

Pseudo message ID is added to recognize handshake message and use the 
correct time unit depending on the appropriate configuration parameter.

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

$ git pull https://github.com/gregt5259/geode-native develop

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

https://github.com/apache/geode-native/pull/106.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 #106


commit 28b6536d85990aef41575d44ef11768dbefdb4f0
Author: gregt5259 
Date:   2017-07-05T10:28:53Z

GEODE-2891 connect-timeout violation in C++ Native Client: fix

Pseudo message ID is added to recognize handshake message and use the
correct time unit depending on the appropriate configuration parameter.

commit be95892927b35e66d5c507f136e394aa4b1b0730
Author: gregt5259 
Date:   2017-07-05T10:35:28Z

Remove the file added by mistake

commit 36b5cbb615fca0d337e7902f2d74f6f994d09585
Author: gregt5259 
Date:   2017-07-05T11:13:54Z

Revert "Remove the file added by mistake"

This reverts commit be95892927b35e66d5c507f136e394aa4b1b0730.

commit ad7113401fbe2c2f35ec52d96421dd396d8b6b01
Author: gregt5259 
Date:   2017-07-05T11:14:07Z

Revert "GEODE-2891 connect-timeout violation in C++ Native Client: fix"

This reverts commit 28b6536d85990aef41575d44ef11768dbefdb4f0.

commit f24ad29356488f9b8561a6af144f582a83367c96
Author: gregt5259 
Date:   2017-07-05T11:23:54Z

GEODE-2891 connect-timeout violation in C++ Native Client: fix

Pseudo message ID is added to recognize handshake message and use the
correct time unit depending on the appropriate configuration parameter.




---
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: Geode "minor minor" versions

[Gregory Chase]

You make it sound like Geode is going to stop. That's definitely not true.

What affects Geode's future are the requests the community makes for new
features. Check out our Jira to know what's in our future.

Since this is an open source Apache community, all the planning occurs here
in the open.  I'm trusting you are new to our community?

Updates get triggered as needed whenever there is an important bug to fix
and/or foundational changes that need to be brought to production, even if
they don't create new features right away.


On Tue, Jul 4, 2017 at 4:56 AM, Roi Apelker  wrote:

> Hi,
>
> I understood from previous discussions, that apart from version 1.3 there
> are no other foreseeable versions in the future.
>
>
> * What about "minor minor" versions - 1.1.2? 1.2.1? - what is the
> "trigger" for such versions?
>
> * Are fixes being released as well? Or is it just that their code
> is in github?
>
> Thanks,
> Roi
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
>



-- 
Greg Chase

Product team
http://www.pivotal.io/big-data

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

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

[GitHub] geode-native issue #105: GEODE-2891 connect-timeout violation in C++ Native ...

[pivotal-jbarrett]

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode-native/pull/105
  
@gregt5259 please close this pull request since you opened #106.



---
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: Different member-timeout for particular jvm’s

[Bruce Schuchardt]

I think we would have to send the member-timeout setting in the "join" 
message and distribute it in the membership view message.


I think this is a good idea


On 7/5/17 5:03 AM, Aravind Musigumpula wrote:


Hi,

May be I was not clear in my last mail. My question is that can we 
monitor a jvm based on it’s own member timeout instead ofthe member 
timeout of some other jvm(which is monitoring the thisjvm).


Now if my view is [s1(coordinator), s2, s3, s4, s5] and member timeout 
for each member is different, the member s3 will suspect s4 on the 
basis of s3 member timeout and then final check will be done by 
coordinator member timeout. Every time the view changes, the order of 
monitoring also changes. So we cannot determine for how much time will 
a particular jvm will be removed from the view.


This can be solved if we use the member timeout of the jvm which is 
being monitored by the current member.


In the above view suppose s3 is monitoring s4. Now s3 marks s4 as 
suspect member on the basis of  s3 member timeout. Instead of this if 
s3 gets the member timeout of s4 and uses this new timeout to monitor 
s4, then we can determine for how much time a member will be removed 
from the view.


Is there any way to get the member timeout of one member from an another ?

Thanks,

Aravind Musigumpula

*From:*Aravind Musigumpula
*Sent:* Monday, July 03, 2017 9:35 PM
*To:* u...@geode.apache.org
*Cc:* bschucha...@pivotal.io
*Subject:* RE: Different member-timeout for particular jvm’s

Hi,

Can the member-timeout of a particular jvm can be used by the 
monitoring jvm.


Example: jvm1 monitors jvm2, jvm2 monitors jvm 3. Member timeout for 
jvm1 is 10, jvm2 is 20 and jvm3 is 30. Suppose the jvm4 is coordinator 
and its member timeout is 30. So what if we want jvm1 should be 
monitored by other jvm’s for a deterministic time like 10 and jvm2 
should be monitored for 20.


Right now, I understand that a jvm will be monitored by member timeout 
of the monitoring jvm and coordinator. My requirement is the each jvm 
should be monitored by its own member timeout followed by 
coordinator’s member-timeout.


In code there is a wait for a member timeout variable in 
GMSHealthMonitor.java.


*if*(pingResp.getResponseMsg() == *null*) {

pingResp.wait(memberTimeout);

  }

What if we get the member timeout of the jvm which is monitored by 
this one. We can do this in setNextNeighborfunction 
inGMSHealthMonitor.java


But how to get the member-timeout of other jvm. Is it possible?

Thanks,

Aravind Musigumpula

*From:*Bruce Schuchardt [mailto:bschucha...@pivotal.io]
*Sent:* Tuesday, June 20, 2017 9:16 PM
*To:* u...@geode.apache.org 
*Subject:* Re: Different member-timeout for particular jvm’s

It is the membership coordinator that performs the final check on a 
suspect member.  If you have network partition detection enabled or 
are using authentication of peers the role of membership coordinator 
will be a locator (if one is in the system) so in your scenario it 
will be the Locator that performs this check.  It will use its own 
member-timeout to determine how long to wait for a response to a 
"final check" message to the suspected member.


If the Locator is down then the oldest member in the system will take 
over the role.  This might be server1 if the membership view is [ s1, 
s2, s4, s3 ].  If there is a problem with s2 then s1 will use its own 
member-timeout setting to determine how long to wait for a final-check 
response from s1.


On 6/20/17 8:18 AM, Aravind Musigumpula wrote:

Hi,

Is there any way to configure different member-timeout for
particular jvm’s.

According to my understanding each jvm monitors its neighbor. If
any jvm is missing heart beat from its neighbor, it waits for
member-timeout interval and sends a suspect message. Then
Coordinator tries to contact that particular jvm, if it is unable
to connect to that jvm. Coordinator waits for its configured
member-timeout interval and removes that member if it is unable to
connect to that jvm.

Scenario:

Locator: member-timeout=1

Server1: member-timeout=2

Server2: member-timeout=3

Server3: member-timeout=2

Server4: member-timeout=2

Suppose server1 is monitoring server2. I made server2 stuck. So
server1 tries to contact the server2 , waits for 2ms and sends
suspect message. Then locator tries to connect with server2 , if
unable to connect waits for 1 and removes server3 from view.

My requirement is I don’t want to kick server2 until 4ms. This
can be done by setting 3 for the jvm which monitors server2.
But how can we see that this particular jvm monitors server2. In
my case every time different jvm is monitoring server2.

Please correct me if I am wrong.

Thanks,

Aravind Musigumpula

This message and the information contained herein is proprietary
and confident

[GitHub] geode-native issue #106: GEODE-2891 connect-timeout violation in C++ Native ...

[echobravopapa]

Github user echobravopapa commented on the issue:

https://github.com/apache/geode-native/pull/106
  
@gregt5259 a couple quick items of feedback that need to be addressed 
before this is reviewed:

- please squash your commits, this cleans up the diffs for everyone to 
better review your contribution
please close [#105](https://github.com/apache/geode-native/pull/105) as 
duplicate of this PR
- please have a look at the [Code 
Contribution](https://cwiki.apache.org/confluence/display/GEODE/Code+contributions)
 section of the WIKI
-- for one you will see that we are using GitFlow and your PR should be 
coming in from a feature branch (e.g.  feature/GEODE-2891) instead of your 
develop branch

 Thanks!


---
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: Geode "minor minor" versions

[Roi Apelker]

I am sorry if I have been misunderstood (and yes I am new :-) )

I did not mean that GEODE is going to stop, I was referring to the subject of 
minor versions.

Is there any plan to release a 1.1.2, or a 1.2.1, or will this be simply an "ad 
hoc" situation, such that only an important bug fix will trigger it... I 
understand now that this is the case.

-Original Message-
From: Gregory Chase [mailto:gch...@pivotal.io] 
Sent: Wednesday, July 05, 2017 5:25 PM
To: dev@geode.apache.org
Subject: Re: Geode "minor minor" versions

You make it sound like Geode is going to stop. That's definitely not true.

What affects Geode's future are the requests the community makes for new 
features. Check out our Jira to know what's in our future.

Since this is an open source Apache community, all the planning occurs here in 
the open.  I'm trusting you are new to our community?

Updates get triggered as needed whenever there is an important bug to fix 
and/or foundational changes that need to be brought to production, even if they 
don't create new features right away.


On Tue, Jul 4, 2017 at 4:56 AM, Roi Apelker  wrote:

> Hi,
>
> I understood from previous discussions, that apart from version 1.3 
> there are no other foreseeable versions in the future.
>
>
> * What about "minor minor" versions - 1.1.2? 1.2.1? - what is the
> "trigger" for such versions?
>
> * Are fixes being released as well? Or is it just that their code
> is in github?
>
> Thanks,
> Roi
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer < 
> https://www.amdocs.com/about/email-disclaimer>
>



--
Greg Chase

Product team
http://www.pivotal.io/big-data

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

650-215-0477
@GregChase
Blog: http://geekmarketing.biz/
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

Re: Geode "minor minor" versions

[Gregory Chase]

On Wed, Jul 5, 2017 at 7:58 AM, Roi Apelker  wrote:
>
>
> Is there any plan to release a 1.1.2, or a 1.2.1, or will this be simply
> an "ad hoc" situation, such that only an important bug fix will trigger
> it... I understand now that this is the case.


The simple answer is "yes", both may apply.

If there is a new feature you are interested in, and possibly helping
contribute to, you can suggest releases to accelerate adoption and testing.

-- 
Greg Chase

Product team
http://www.pivotal.io/big-data

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

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

[GitHub] geode-native issue #106: GEODE-2891 connect-timeout violation in C++ Native ...

[pivotal-jbarrett]

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode-native/pull/106
  
@echobravopapa the branching scheme only applies to committers working 
directly with the Geode repositories. Non-committers use pull requests which 
render the branching/girflow requirement null.


---
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] geode-native issue #106: GEODE-2891 connect-timeout violation in C++ Native ...

[echobravopapa]

Github user echobravopapa commented on the issue:

https://github.com/apache/geode-native/pull/106
  
@pivotal-jbarrett fair enough on the branching point, I think the rest is 
still a valid ask


---
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] geode pull request #615: GEODE-2991 Add man page for gfsh destroy gateway-se...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/615


---
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] geode pull request #618: GEODE-3167: Added commons-validator dependency to m...

[DivineEnder]

GitHub user DivineEnder opened a pull request:

https://github.com/apache/geode/pull/618

GEODE-3167: Added commons-validator dependency to modify_war script a…

…nd Tomcat required jars

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/DivineEnder/geode feature/GEODE-3167

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

https://github.com/apache/geode/pull/618.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 #618


commit 5d5ede50a1367f6851b3c9eb5db7a843b84cb4ac
Author: David Anuta 
Date:   2017-07-05T17:12:01Z

GEODE-3167: Added commons-validator dependency to modify_war script and 
Tomcat required jars




---
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] geode issue #618: GEODE-3167: Added commons-validator dependency to modify_w...

[DivineEnder]

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/618
  
@ladyVader @nabarunnag @boglesby @jhuynh1 @upthewaterspout @gesterzhou 


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

Re: Review Request 60629: GEODE-3129 - Added error messages to protobuf protocol

[Alexander Murmann]

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


Fix it, then Ship it!




Ship It!


geode-protobuf/src/test/java/org/apache/geode/protocol/protobuf/operations/GetRequestOperationHandlerJUnitTest.java
Lines 97 (patched)


Do we care if the `retriable` flag is set?


- Alexander Murmann


On July 3, 2017, 11:40 p.m., Brian Rowe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60629/
> ---
> 
> (Updated July 3, 2017, 11:40 p.m.)
> 
> 
> Review request for geode, Alexander Murmann, Bruce Schuchardt, Galen 
> O'Sullivan, Hitesh Khamesra, and Udo Kohlmeyer.
> 
> 
> Bugs: GEODE-3129
> https://issues.apache.org/jira/browse/GEODE-3129
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> added a new ErrorResponse type to ClientProtocol
> removed success field from several RegionAPI response objects and refactored 
> operation handlers to instead return ErrorResponses
> made all op handlers take ClientProtocol.Requests and return 
> ClientProtocol.Responses instead of operation specific types
> moved the protobuf specific response building code from operation handlers to 
> ProtobufResponseUtilities
> moved the request building functions from MessageUtil (under Test) to 
> ProtobufRequestUtilities
> moved all utility classes to ...protocol.protobuf.utilities and added javadoc 
> comments throughout
> changed GetRegions to GetRegionNames, returns strings instead of Regions
> replaced logging through the cache's LogWriter with log4j logging
> updated all imports to be in the correct order for the new geode style guide
> 
> 
> Diffs
> -
> 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/OperationsHandlerRegistry.java
>  2b9f52597 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/EncodingTypeTranslator.java
>  edb7c7eb1 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufOpsProcessor.java
>  4318fb444 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufStreamProcessor.java
>  4e76de4a1 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufUtilities.java
>  c92da67a2 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/operations/GetRegionsRequestOperationHandler.java
>  dc1d8acdd 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/operations/GetRequestOperationHandler.java
>  95026e8d7 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/operations/PutRequestOperationHandler.java
>  f375244d8 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/serializer/ProtobufProtocolSerializer.java
>  683e42f3f 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/utilities/ProtobufRequestUtilities.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/utilities/ProtobufResponseUtilities.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/utilities/ProtobufUtilities.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/IntCodec.java
>  6bd2b5c91 
>   geode-protobuf/src/main/proto/clientProtocol.proto 0c192950a 
>   geode-protobuf/src/main/proto/region_API.proto d3af17acb 
>   
> geode-protobuf/src/test/java/org/apache/geode/protocol/IntegrationJUnitTest.java
>  42cc7b3d0 
>   geode-protobuf/src/test/java/org/apache/geode/protocol/MessageUtil.java 
> dc897241f 
>   
> geode-protobuf/src/test/java/org/apache/geode/protocol/RoundTripCacheConnectionJUnitTest.java
>  77b984f7e 
>   
> geode-protobuf/src/test/java/org/apache/geode/protocol/operations/registry/OperationsHandlerRegistryJUnitTest.java
>  612e6a76f 
>   
> geode-protobuf/src/test/java/org/apache/geode/protocol/protobuf/EncodingTypeToSerializationTypeTranslatorJUnitTest.java
>  8e6f66aae 
>   
> geode-protobuf/src/test/java/org/apache/geode/protocol/protobuf/ProtobufOpsProcessorJUnitTest.java
>  c51be5cbb 
>   
> geode-protobuf/src/test/java/org/apache/geode/protocol/protobuf/operations/GetRegionRequestOperationHandlerJUnitTest.java
>  e8f1e651a 
>   
> geode-protobuf/src/test/java/org/apache/geode/protocol/protobuf/operations/GetRequestOperationHandlerJUnitTest.java
>  f92b1941a 
>   
> geode-protobuf/src/test/java/org/apache/geode/protocol/protobuf/operations/PutRequestOperationHandlerJUnitTest.java
>  ddc23fc42 
>   
> geode-protobuf/src/test/java/org/apache/geode/protocol/serializer/ProtobufProtocolSerializerJUnitTest.java
>  5a94dae01 
>   
> geode-protobuf/src/test/java/org/apache/geode/serialization/code

Re: Geode "minor minor" versions

[Michael Stolz]

@Roi Apelker: There is a big effort going on right now in the community to
get a 1.2 release of Geode out.
You can follow the release notes here:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.2.0

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Wed, Jul 5, 2017 at 10:58 AM, Roi Apelker  wrote:

> I am sorry if I have been misunderstood (and yes I am new :-) )
>
> I did not mean that GEODE is going to stop, I was referring to the subject
> of minor versions.
>
> Is there any plan to release a 1.1.2, or a 1.2.1, or will this be simply
> an "ad hoc" situation, such that only an important bug fix will trigger
> it... I understand now that this is the case.
>
> -Original Message-
> From: Gregory Chase [mailto:gch...@pivotal.io]
> Sent: Wednesday, July 05, 2017 5:25 PM
> To: dev@geode.apache.org
> Subject: Re: Geode "minor minor" versions
>
> You make it sound like Geode is going to stop. That's definitely not true.
>
> What affects Geode's future are the requests the community makes for new
> features. Check out our Jira to know what's in our future.
>
> Since this is an open source Apache community, all the planning occurs
> here in the open.  I'm trusting you are new to our community?
>
> Updates get triggered as needed whenever there is an important bug to fix
> and/or foundational changes that need to be brought to production, even if
> they don't create new features right away.
>
>
> On Tue, Jul 4, 2017 at 4:56 AM, Roi Apelker 
> wrote:
>
> > Hi,
> >
> > I understood from previous discussions, that apart from version 1.3
> > there are no other foreseeable versions in the future.
> >
> >
> > * What about "minor minor" versions - 1.1.2? 1.2.1? - what is the
> > "trigger" for such versions?
> >
> > * Are fixes being released as well? Or is it just that their code
> > is in github?
> >
> > Thanks,
> > Roi
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at https://www.amdocs.com/about/email-disclaimer <
> > https://www.amdocs.com/about/email-disclaimer>
> >
>
>
>
> --
> Greg Chase
>
> Product team
> http://www.pivotal.io/big-data
>
> Pivotal Software
> http://www.pivotal.io/
>
> 650-215-0477
> @GregChase
> Blog: http://geekmarketing.biz/
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
>

Review Request 60664: GEODE-3153 Client receives duplicate events during rolling upgrade

[Bruce Schuchardt]

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

Review request for geode, Barry Oglesby, Hitesh Khamesra, and Dan Smith.


Bugs: geode-3153
https://issues.apache.org/jira/browse/geode-3153


Repository: geode


Description
---

The previous fix worked fine for 1.0.0 and 1.1.0 clients but there are old 
GemFire 8.2 clients still in use that the fix did not work for.  This patch 
changes the serialization to always send UUID bytes to pre Version.GFE_90 
(1.0.0-incubating) clients.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
 85c2bea467b115c4fe5f0ea51ef053d26e300a58 
  geode-core/src/main/java/org/apache/geode/internal/cache/EventID.java 
86216497caad3f18debcc6a81182caadc8b7e487 


Diff: https://reviews.apache.org/r/60664/diff/1/


Testing
---

Precheckin is under way.  Barry gave me a manual test using an 8.2 client that 
is now passing.  Steps are:
start 1.0.0 locator and server
start 8.x client that registers interest
start 1.2 server
push data using a 1.0.0 peer
kill the 1.0.0 server
--> the client should not see duplicate events

Hitesh is writing junit tests for the EventID changes.


Thanks,

Bruce Schuchardt

Review Request 60666: geode-3166: remove the uncalled getCredential method

[Jinmei Liao]

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

Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

geode-3166: remove the uncalled getCredential method

I simply removed the call. Since the new method is never called, if we have any 
users that's implementing this method, it's never used anyway. We will not be 
breaking backward compatibility, I believe.


Diffs
-

  geode-core/src/main/java/org/apache/geode/security/AuthInitialize.java 
6b0675a5629a3e057fd3d54841db740189007966 


Diff: https://reviews.apache.org/r/60666/diff/1/


Testing
---

precheckin running


Thanks,

Jinmei Liao

[GitHub] geode pull request #618: GEODE-3167: Added commons-validator dependency to m...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/618


---
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: Geode "minor minor" versions

[Dan Smith]

Hi Roi,


> Is there any plan to release a 1.1.2, or a 1.2.1, or will this be simply
> an "ad hoc" situation, such that only an important bug fix will trigger
> it... I understand now that this is the case.
>

That's exactly it. We'll only release a newer minor revision of older
version of geode if there is a bug fix that the PMC decides is important
enough that we need to patch that old version. Hopefully we won't see too
many of those :)

Currently we're trying to get 1.2 out the door and the next planned release
is 1.3.

-Dan

Re: Review Request 60664: GEODE-3153 Client receives duplicate events during rolling upgrade

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On July 5, 2017, 7:01 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60664/
> ---
> 
> (Updated July 5, 2017, 7:01 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, Hitesh Khamesra, and Dan Smith.
> 
> 
> Bugs: geode-3153
> https://issues.apache.org/jira/browse/geode-3153
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The previous fix worked fine for 1.0.0 and 1.1.0 clients but there are old 
> GemFire 8.2 clients still in use that the fix did not work for.  This patch 
> changes the serialization to always send UUID bytes to pre Version.GFE_90 
> (1.0.0-incubating) clients.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
>  85c2bea467b115c4fe5f0ea51ef053d26e300a58 
>   geode-core/src/main/java/org/apache/geode/internal/cache/EventID.java 
> 86216497caad3f18debcc6a81182caadc8b7e487 
> 
> 
> Diff: https://reviews.apache.org/r/60664/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin is under way.  Barry gave me a manual test using an 8.2 client 
> that is now passing.  Steps are:
> start 1.0.0 locator and server
> start 8.x client that registers interest
> start 1.2 server
> push data using a 1.0.0 peer
> kill the 1.0.0 server
> --> the client should not see duplicate events
> 
> Hitesh is writing junit tests for the EventID changes.
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 60664: GEODE-3153 Client receives duplicate events during rolling upgrade

[Barry Oglesby]

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


Ship it!




Ship It!

- Barry Oglesby


On July 5, 2017, 7:01 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60664/
> ---
> 
> (Updated July 5, 2017, 7:01 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, Hitesh Khamesra, and Dan Smith.
> 
> 
> Bugs: geode-3153
> https://issues.apache.org/jira/browse/geode-3153
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The previous fix worked fine for 1.0.0 and 1.1.0 clients but there are old 
> GemFire 8.2 clients still in use that the fix did not work for.  This patch 
> changes the serialization to always send UUID bytes to pre Version.GFE_90 
> (1.0.0-incubating) clients.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
>  85c2bea467b115c4fe5f0ea51ef053d26e300a58 
>   geode-core/src/main/java/org/apache/geode/internal/cache/EventID.java 
> 86216497caad3f18debcc6a81182caadc8b7e487 
> 
> 
> Diff: https://reviews.apache.org/r/60664/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin is under way.  Barry gave me a manual test using an 8.2 client 
> that is now passing.  Steps are:
> start 1.0.0 locator and server
> start 8.x client that registers interest
> start 1.2 server
> push data using a 1.0.0 peer
> kill the 1.0.0 server
> --> the client should not see duplicate events
> 
> Hitesh is writing junit tests for the EventID changes.
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #607 was successful.
---
Scheduled
1910 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[GitHub] geode pull request #619: Feature/geode 2901

[DivineEnder]

GitHub user DivineEnder opened a pull request:

https://github.com/apache/geode/pull/619

Feature/geode 2901

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/DivineEnder/geode feature/GEODE-2901

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

https://github.com/apache/geode/pull/619.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 #619


commit 5d5ede50a1367f6851b3c9eb5db7a843b84cb4ac
Author: David Anuta 
Date:   2017-07-05T17:12:01Z

GEODE-3167: Added commons-validator dependency to modify_war script and 
Tomcat required jars

commit e1b5570bac6d56bce6132daa93c84e39938f5f88
Author: David Anuta 
Date:   2017-07-03T23:55:03Z

Updating installation and container management to allow more container 
independence (just in time for the 4th)

commit 2350d37f294bf8a03a45cc8626522dcd1b610440
Author: David Anuta 
Date:   2017-07-04T00:12:29Z

Fixed incorrect local cache enabled property setting for jetty and tomcat

Setting has previously been set as a cache property as enableLocalCache. 
Jetty needs the cache property enable_local_cache so moved the setting of this 
property within each container (Tomcat and Jetty) with their respective 
variable names

commit 1ad5395befdf330b35b931624a0bf79155dafa0f
Author: David Anuta 
Date:   2017-07-05T23:21:27Z

Fixed server.xml so that it was no longer installation specific

Previously, each container edited the same file, which led to some 
concurrency issues. Now the configuration holds the server xml configuration 
and only writes it to the configuration folder when a container is started.




---
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] geode issue #619: Feature/geode 2901

[DivineEnder]

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/619
  
@ladyVader @nabarunnag @boglesby @jhuynh1 @upthewaterspout @gesterzhou 


---
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] geode issue #619: Feature/geode 2901

[DivineEnder]

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/619
  
Still working on adding javadoc, but the actual code is all in place


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

Build failed in Jenkins: Geode-nightly #887

[Apache Jenkins Server]

See 

--
[...truncated 53.42 KB...]
:extensions/geode-modules-session:testClasses
:extensions/geode-modules-session:checkMissedTests
:extensions/geode-modules-session:spotlessJavaCheck
:extensions/geode-modules-session:spotlessCheck
:extensions/geode-modules-session:test
:extensions/geode-modules-session:check
:extensions/geode-modules-session:build
:extensions/geode-modules-session:distributedTest
:extensions/geode-modules-session:integrationTest
:extensions/geode-modules-session-internal:javadocJar
:extensions/geode-modules-session-internal:sourcesJar
:extensions/geode-modules-session-internal:signArchives SKIPPED
:extensions/geode-modules-session-internal:assemble
:extensions/geode-modules-session-internal:compileTestJava UP-TO-DATE
:extensions/geode-modules-session-internal:processTestResources UP-TO-DATE
:extensions/geode-modules-session-internal:testClasses UP-TO-DATE
:extensions/geode-modules-session-internal:checkMissedTests UP-TO-DATE
:extensions/geode-modules-session-internal:spotlessJavaCheck
:extensions/geode-modules-session-internal:spotlessCheck
:extensions/geode-modules-session-internal:test UP-TO-DATE
:extensions/geode-modules-session-internal:check
:extensions/geode-modules-session-internal:build
:extensions/geode-modules-session-internal:distributedTest UP-TO-DATE
:extensions/geode-modules-session-internal:integrationTest UP-TO-DATE
:extensions/geode-modules-tomcat7:compileTestJava
:extensions/geode-modules-tomcat7:processTestResources
:extensions/geode-modules-tomcat7:testClasses
:extensions/geode-modules-tomcat7:checkMissedTests
:extensions/geode-modules-tomcat7:spotlessJavaCheck
:extensions/geode-modules-tomcat7:spotlessCheck
:extensions/geode-modules-tomcat7:test
:extensions/geode-modules-tomcat7:check
:extensions/geode-modules-tomcat7:build
:extensions/geode-modules-tomcat7:distributedTest
:extensions/geode-modules-tomcat7:integrationTest
:extensions/geode-modules-tomcat8:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

:extensions/geode-modules-tomcat8:processTestResources
:extensions/geode-modules-tomcat8:testClasses
:extensions/geode-modules-tomcat8:checkMissedTests
:extensions/geode-modules-tomcat8:spotlessJavaCheck
:extensions/geode-modules-tomcat8:spotlessCheck
:extensions/geode-modules-tomcat8:test
:extensions/geode-modules-tomcat8:check
:extensions/geode-modules-tomcat8:build
:extensions/geode-modules-tomcat8:distributedTest
:extensions/geode-modules-tomcat8:integrationTest
:extensions/session-testing-war:compileJava
:extensions/session-testing-war:processResources UP-TO-DATE
:extensions/session-testing-war:classes
:extensions/session-testing-war:javadoc
:extensions/session-testing-war:javadocJar
:extensions/session-testing-war:sourcesJar
:extensions/session-testing-war:war
:extensions/session-testing-war:signArchives SKIPPED
:extensions/session-testing-war:assemble
:extensions/session-testing-war:compileTestJava UP-TO-DATE
:extensions/session-testing-war:processTestResources UP-TO-DATE
:extensions/session-testing-war:testClasses UP-TO-DATE
:extensions/session-testing-war:checkMissedTests UP-TO-DATE
:extensions/session-testing-war:spotlessJavaCheck
:extensions/session-testing-war:spotlessCheck
:extensions/session-testing-war:test UP-TO-DATE
:extensions/session-testing-war:check
:extensions/session-testing-war:build
:extensions/session-testing-war:distributedTest UP-TO-DATE
:extensions/session-testing-war:integrationTest UP-TO-DATE
:geode-assembly:compileJava UP-TO-DATE
:geode-assembly:processResources UP-TO-DATE
:geode-assembly:classes UP-TO-DATE
:geode-assembly:defaultCacheConfig
:geode-assembly:defaultDistributionConfig
:geode-assembly:depsJar
:geode-benchmarks:compileJava UP-TO-DATE
:geode-benchmarks:processResources UP-TO-DATE
:geode-benchmarks:classes UP-TO-DATE
:geode-cq:compileJavaNote: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processResources
:geode-cq:classes
:geode-lucene:compileJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processResources
:geode-lucene:classes
:geode-old-client-support:compileJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.

:geode-old-client-support:processResources
:geode-old-client-support:classes
:geode-protobuf:extractIncludeProto
:geode-protobuf:extractProto UP-TO-DATE
:geode-protobuf:generat

Jenkins build is back to normal : Geode-nightly-flaky #56

[Apache Jenkins Server]

See