Re: Review Request 60106: GEODE-3052 Restarting 2 locators within 1s of each other causes potential locator split brain

[Hitesh Khamesra]

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


Ship it!




Ship It!

- Hitesh Khamesra


On June 21, 2017, 10:24 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60106/
> ---
> 
> (Updated June 21, 2017, 10:24 p.m.)
> 
> 
> Review request for geode, Alexander Murmann, Galen O'Sullivan, Hitesh 
> Khamesra, and Brian Rowe.
> 
> 
> Bugs: GEODE-3052
> https://issues.apache.org/jira/browse/GEODE-3052
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> There were four problems that new unit tests hit:
> 1. when recovering a view from disk we were treating it as a definitive 
> (live) view.  I've moved it to a new variable in GMSLocator and set its 
> viewId to -1.  At the same time I set the initial GMSJoinLeave 
> SearchState.viewId to -100 so it will be overridden by the one returned by 
> the locator.  These changes allow GmsJoinLeave to know that the potential 
> coordinator is from a recovered view.
> 2. when trying to join with a recovered view GMSJoinLeave.join() was giving 
> up after the second ID in the view and becoming the coordinator.  It needs to 
> keep trying until the list is exhausted, and it shouldn't sleep between 
> attempts.
> 3. GMSLocator wasn't returning registrants for use in 
> findCoordinatorFromView().  This was causing it to choose itself as the 
> coordinator instead of using registrant sort order and choosing a different 
> registrant as the coordinator.
> 4. During concurrent startup GMSLocator didn't know when the decision was 
> made to become coordinator.  It is now notified of this decision and 
> processRequest() uses this flag to have it override anything in the 
> registrants set or in the recovered view.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/NetView.java
>  26b03276b0abbf6210a5602a8c551abe38edc261 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSUtil.java
>  c6bef571134c6444a297cc8fe0bb0b7eb95f41f4 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/interfaces/Locator.java
>  c5fdf45411581a36feca220e14a0551f3197d368 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/FindCoordinatorResponse.java
>  edfaf625e6c652f46d9323c1116791f1c69fda59 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/GMSLocator.java
>  93fa9dab4ec2c8e43fc41cfd3b8ad986f96cf00f 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  8abcc456e42ad00a558a93f87bd3ae74ce88d146 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/GMSEncrypt.java
>  c7b1a26b47cf2c913d9de30d6934ad5b3ac49840 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/JGroupsMessenger.java
>  390824eb11a2e72a21d951539c2e03ed8025be82 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
> 7ecca6146f6b7a542ae9864d7fabd48c9794ecac 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorUDPSecurityDUnitTest.java
>  df1d8d1101a5f9d04c402922955a283353aa3b7c 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeaveTestHelper.java
>  19cee066a488198471ebf4093045853e36d5ba78 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/messenger/GMSEncryptJUnitTest.java
>  7f64c670400464aa8e6a73405516bd6e891a006b 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
>  b35270e2d97930cee68d8c54221a04c20dfb96de 
> 
> 
> Diff: https://reviews.apache.org/r/60106/diff/2/
> 
> 
> Testing
> ---
> 
> New unit tests, regression testing (under way), precheckin (under way)
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 60106: GEODE-3052 Restarting 2 locators within 1s of each other causes potential locator split brain

[Hitesh Khamesra]

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



not sure you saw following commant, as I was having trouble with reviewboard.


geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/GMSLocator.java
 (Diff revision 2)
235 
if (v == null) {
we are setting -1 viewid for recorded view while recovery. Thus do we need 
"usingRecoveredView" flag here?

- Hitesh Khamesra


On June 21, 2017, 10:24 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60106/
> ---
> 
> (Updated June 21, 2017, 10:24 p.m.)
> 
> 
> Review request for geode, Alexander Murmann, Galen O'Sullivan, Hitesh 
> Khamesra, and Brian Rowe.
> 
> 
> Bugs: GEODE-3052
> https://issues.apache.org/jira/browse/GEODE-3052
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> There were four problems that new unit tests hit:
> 1. when recovering a view from disk we were treating it as a definitive 
> (live) view.  I've moved it to a new variable in GMSLocator and set its 
> viewId to -1.  At the same time I set the initial GMSJoinLeave 
> SearchState.viewId to -100 so it will be overridden by the one returned by 
> the locator.  These changes allow GmsJoinLeave to know that the potential 
> coordinator is from a recovered view.
> 2. when trying to join with a recovered view GMSJoinLeave.join() was giving 
> up after the second ID in the view and becoming the coordinator.  It needs to 
> keep trying until the list is exhausted, and it shouldn't sleep between 
> attempts.
> 3. GMSLocator wasn't returning registrants for use in 
> findCoordinatorFromView().  This was causing it to choose itself as the 
> coordinator instead of using registrant sort order and choosing a different 
> registrant as the coordinator.
> 4. During concurrent startup GMSLocator didn't know when the decision was 
> made to become coordinator.  It is now notified of this decision and 
> processRequest() uses this flag to have it override anything in the 
> registrants set or in the recovered view.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/NetView.java
>  26b03276b0abbf6210a5602a8c551abe38edc261 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSUtil.java
>  c6bef571134c6444a297cc8fe0bb0b7eb95f41f4 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/interfaces/Locator.java
>  c5fdf45411581a36feca220e14a0551f3197d368 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/FindCoordinatorResponse.java
>  edfaf625e6c652f46d9323c1116791f1c69fda59 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/GMSLocator.java
>  93fa9dab4ec2c8e43fc41cfd3b8ad986f96cf00f 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  8abcc456e42ad00a558a93f87bd3ae74ce88d146 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/GMSEncrypt.java
>  c7b1a26b47cf2c913d9de30d6934ad5b3ac49840 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/JGroupsMessenger.java
>  390824eb11a2e72a21d951539c2e03ed8025be82 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
> 7ecca6146f6b7a542ae9864d7fabd48c9794ecac 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorUDPSecurityDUnitTest.java
>  df1d8d1101a5f9d04c402922955a283353aa3b7c 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeaveTestHelper.java
>  19cee066a488198471ebf4093045853e36d5ba78 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/messenger/GMSEncryptJUnitTest.java
>  7f64c670400464aa8e6a73405516bd6e891a006b 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
>  b35270e2d97930cee68d8c54221a04c20dfb96de 
> 
> 
> Diff: https://reviews.apache.org/r/60106/diff/2/
> 
> 
> Testing
> ---
> 
> New unit tests, regression testing (under way), precheckin (under way)
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

[GitHub] geode issue #586: GEODE-3075: initial flow adding the new client protocol to...

[galen-pivotal]

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/586
  
This failed due to Spotless; closing in favor of #597.


---
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 #586: GEODE-3075: initial flow adding the new client prot...

[galen-pivotal]

Github user galen-pivotal closed the pull request at:

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


---
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 60347: GEODE-3097: GFSH works over HTTP with SSL

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On June 21, 2017, 10:48 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60347/
> ---
> 
> (Updated June 21, 2017, 10:48 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3097: GFSH works over HTTP with SSL
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ShellCommands.java
>  2da95a7c3f305aab4e615d4be7b14c19b9b31dbc 
>   
> geode-core/src/test/java/org/apache/geode/management/ConnectToLocatorSSLDUnitTest.java
>  844e0322eecdc93c4d46c546f4df2d278c5f15cd 
> 
> 
> Diff: https://reviews.apache.org/r/60347/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 60106: GEODE-3052 Restarting 2 locators within 1s of each other causes potential locator split brain

[Bruce Schuchardt]

> On June 21, 2017, 11:05 p.m., Hitesh Khamesra wrote:
> > geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
> > Lines 710 (patched)
> > 
> >
> > In which condition we need to initialize cluster key here?

This is the case where another member has decided that this member will become 
the coordinator but this member has not gotten to the point of starting its 
coordinator services.


> On June 21, 2017, 11:05 p.m., Hitesh Khamesra wrote:
> > geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
> > Lines 800 (patched)
> > 
> >
> > This looks good one!!

Thanks!


> On June 21, 2017, 11:05 p.m., Hitesh Khamesra wrote:
> > geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java
> > Lines 1748 (patched)
> > 
> >
> > Very good test Bruce.

I like the blackboard!


> On June 21, 2017, 11:05 p.m., Hitesh Khamesra wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
> > Line 79 (original), 79 (patched)
> > 
> >
> > do we want fine level log here?

Thank you - I've reverted that change.  It was for debugging.


- Bruce


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


On June 21, 2017, 10:24 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60106/
> ---
> 
> (Updated June 21, 2017, 10:24 p.m.)
> 
> 
> Review request for geode, Alexander Murmann, Galen O'Sullivan, Hitesh 
> Khamesra, and Brian Rowe.
> 
> 
> Bugs: GEODE-3052
> https://issues.apache.org/jira/browse/GEODE-3052
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> There were four problems that new unit tests hit:
> 1. when recovering a view from disk we were treating it as a definitive 
> (live) view.  I've moved it to a new variable in GMSLocator and set its 
> viewId to -1.  At the same time I set the initial GMSJoinLeave 
> SearchState.viewId to -100 so it will be overridden by the one returned by 
> the locator.  These changes allow GmsJoinLeave to know that the potential 
> coordinator is from a recovered view.
> 2. when trying to join with a recovered view GMSJoinLeave.join() was giving 
> up after the second ID in the view and becoming the coordinator.  It needs to 
> keep trying until the list is exhausted, and it shouldn't sleep between 
> attempts.
> 3. GMSLocator wasn't returning registrants for use in 
> findCoordinatorFromView().  This was causing it to choose itself as the 
> coordinator instead of using registrant sort order and choosing a different 
> registrant as the coordinator.
> 4. During concurrent startup GMSLocator didn't know when the decision was 
> made to become coordinator.  It is now notified of this decision and 
> processRequest() uses this flag to have it override anything in the 
> registrants set or in the recovered view.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/NetView.java
>  26b03276b0abbf6210a5602a8c551abe38edc261 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSUtil.java
>  c6bef571134c6444a297cc8fe0bb0b7eb95f41f4 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/interfaces/Locator.java
>  c5fdf45411581a36feca220e14a0551f3197d368 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/FindCoordinatorResponse.java
>  edfaf625e6c652f46d9323c1116791f1c69fda59 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/GMSLocator.java
>  93fa9dab4ec2c8e43fc41cfd3b8ad986f96cf00f 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  8abcc456e42ad00a558a93f87bd3ae74ce88d146 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/GMSEncrypt.java
>  c7b1a26b47cf2c913d9de30d6934ad5b3ac49840 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/JGroupsMessenger.java
>  390824eb11a2e72a21d951539c2e03ed8025be82 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
> 7ecca6146f6b7a542ae9864d7fabd48c9794ecac 
>   
> 

[GitHub] geode pull request #591: GEODE-3073: Renamed OrderByComparatorUnmapped to Or...

[jhuynh1]

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode/pull/591#discussion_r123388223
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledSelect.java
 ---
@@ -925,79 +917,89 @@ private SelectResults 
applyProjectionOnCollection(SelectResults resultSet,
 
   private SelectResults prepareEmptyResultSet(ExecutionContext context, 
boolean ignoreOrderBy)
   throws TypeMismatchException, AmbiguousNameException {
-// if no projection attributes or '*'as projection attribute
-// & more than one/RunTimeIterator then create a StrcutSet.
-// If attribute is null or '*' & only one RuntimeIterator then create a
-// ResultSet.
-// If single attribute is present without alias name , then create
-// ResultSet
-// Else if more than on attribute or single attribute with alias is
-// present then return a StrcutSet
-// create StructSet which will contain root objects of all iterators in
-// from clause
+// If no projection attributes or '*' as projection attribute & more 
than one/RunTimeIterator
+// then create a StructSet.
+// If attribute is null or '*' & only one RuntimeIterator then create 
a ResultSet.
+// If single attribute is present without alias name, then create 
ResultSet.
+// Else if more than on attribute or single attribute with alias is 
present then return a
+// StructSet.
+// Create StructSet which will contain root objects of all iterators 
in from clause.
 
 ObjectType elementType = this.cachedElementTypeForOrderBy != null
 ? this.cachedElementTypeForOrderBy : prepareResultType(context);
 SelectResults results;
-if (this.distinct || !this.count) {
-  if (this.orderByAttrs != null) {
-boolean nullValuesAtStart = !((CompiledSortCriterion) 
orderByAttrs.get(0)).getCriterion();
-if (elementType.isStructType()) {
-  if (ignoreOrderBy) {
-results = this.distinct ? new LinkedStructSet((StructTypeImpl) 
elementType)
-: new SortedResultsBag(elementType, nullValuesAtStart);
 
-  } else {
-OrderByComparator comparator = this.hasUnmappedOrderByCols
-? new OrderByComparatorUnmapped(this.orderByAttrs, 
(StructTypeImpl) elementType,
-context)
-: new OrderByComparator(this.orderByAttrs, 
(StructTypeImpl) elementType, context);
-results = this.distinct ? new SortedStructSet(comparator, 
(StructTypeImpl) elementType)
-: new SortedStructBag(comparator, (StructType) 
elementType, nullValuesAtStart);
+if (!this.distinct && this.count) {
+  // Shobhit: If it's a 'COUNT' query and no End processing required 
Like for 'DISTINCT'
+  // we can directly keep count in ResultSet and ResultBag is good 
enough for that.
+  countStartQueryResult = 0;
+  return new ResultsBag(new ObjectTypeImpl(Integer.class), 1, 
context.getCachePerfStats());
+}
 
-  }
-} else {
-  if (ignoreOrderBy) {
-results =
-this.distinct ? new LinkedResultSet() : new 
SortedResultsBag(nullValuesAtStart);
+// Potential edge-case: Could this be non-null but empty?
+boolean nullValuesAtStart = orderByAttrs != null && 
!orderByAttrs.get(0).getCriterion();
+OrderByComparator comparator;
+switch (convertToStringCase(elementType, ignoreOrderBy)) {
+  case "UNORDERED DISTINCT STRUCT":
+return new StructSet((StructType) elementType);
+  case "UNORDERED DISTINCT RESULTS":
+return new ResultsSet(elementType);
+  case "UNORDERED INDISTINCT STRUCT":
+return new StructBag((StructType) elementType, 
context.getCachePerfStats());
+  case "UNORDERED INDISTINCT RESULTS":
+return new ResultsBag(elementType, context.getCachePerfStats());
+
+  case "ORDERED DISTINCT STRUCT IGNORED":
+return new LinkedStructSet((StructTypeImpl) elementType);
+  case "ORDERED INDISTINCT STRUCT IGNORED":
+return new SortedResultsBag(elementType, nullValuesAtStart);
+  case "ORDERED DISTINCT STRUCT UNIGNORED":
--- End diff --

I think the ignoreOrderBy flag is a bit misleading, otherwise UNORDERED 
DISTINCT STRUCT should technically be the same as ORDERED DISTINCT STRUCT 
IGNORED (since ignoreOrderby is true).  It's almost like a "sort at data 
structure" level or delay the sort until later flag.  

If you decide to keep the naming, would it make sense to not have UNIGNORED 
but rather a no string.  So ORDERED DISTINCT STRUCT  == ORDERED DISTINCT STRUCT 
UNIGNORED


---
If your project is set up for it, you can reply to 

Re: Review Request 60106: GEODE-3052 Restarting 2 locators within 1s of each other causes potential locator split brain

[Hitesh Khamesra]

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




geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
Lines 710 (patched)


In which condition we need to initialize cluster key here?



geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
Lines 800 (patched)


This looks good one!!



geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java
Lines 1748 (patched)


Very good test Bruce.



geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
Line 79 (original), 79 (patched)


do we want fine level log here?


- Hitesh Khamesra


On June 21, 2017, 10:24 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60106/
> ---
> 
> (Updated June 21, 2017, 10:24 p.m.)
> 
> 
> Review request for geode, Alexander Murmann, Galen O'Sullivan, Hitesh 
> Khamesra, and Brian Rowe.
> 
> 
> Bugs: GEODE-3052
> https://issues.apache.org/jira/browse/GEODE-3052
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> There were four problems that new unit tests hit:
> 1. when recovering a view from disk we were treating it as a definitive 
> (live) view.  I've moved it to a new variable in GMSLocator and set its 
> viewId to -1.  At the same time I set the initial GMSJoinLeave 
> SearchState.viewId to -100 so it will be overridden by the one returned by 
> the locator.  These changes allow GmsJoinLeave to know that the potential 
> coordinator is from a recovered view.
> 2. when trying to join with a recovered view GMSJoinLeave.join() was giving 
> up after the second ID in the view and becoming the coordinator.  It needs to 
> keep trying until the list is exhausted, and it shouldn't sleep between 
> attempts.
> 3. GMSLocator wasn't returning registrants for use in 
> findCoordinatorFromView().  This was causing it to choose itself as the 
> coordinator instead of using registrant sort order and choosing a different 
> registrant as the coordinator.
> 4. During concurrent startup GMSLocator didn't know when the decision was 
> made to become coordinator.  It is now notified of this decision and 
> processRequest() uses this flag to have it override anything in the 
> registrants set or in the recovered view.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/NetView.java
>  26b03276b0abbf6210a5602a8c551abe38edc261 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSUtil.java
>  c6bef571134c6444a297cc8fe0bb0b7eb95f41f4 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/interfaces/Locator.java
>  c5fdf45411581a36feca220e14a0551f3197d368 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/FindCoordinatorResponse.java
>  edfaf625e6c652f46d9323c1116791f1c69fda59 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/GMSLocator.java
>  93fa9dab4ec2c8e43fc41cfd3b8ad986f96cf00f 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  8abcc456e42ad00a558a93f87bd3ae74ce88d146 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/GMSEncrypt.java
>  c7b1a26b47cf2c913d9de30d6934ad5b3ac49840 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/JGroupsMessenger.java
>  390824eb11a2e72a21d951539c2e03ed8025be82 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
> 7ecca6146f6b7a542ae9864d7fabd48c9794ecac 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorUDPSecurityDUnitTest.java
>  df1d8d1101a5f9d04c402922955a283353aa3b7c 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeaveTestHelper.java
>  19cee066a488198471ebf4093045853e36d5ba78 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/messenger/GMSEncryptJUnitTest.java
>  7f64c670400464aa8e6a73405516bd6e891a006b 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
>  b35270e2d97930cee68d8c54221a04c20dfb96de 
> 
> 
> Diff: https://reviews.apache.org/r/60106/diff/2/
> 
> 
> Testing
> ---
> 
> New unit tests, regression testing 

Re: Review Request 60106: GEODE-3052 Restarting 2 locators within 1s of each other causes potential locator split brain

[Hitesh Khamesra]

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




geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
Lines 710 (patched)


In which condition we need to initialize cluster key here?



geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
Lines 800 (patched)


This looks good one!!



geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java
Lines 1748 (patched)


Very good test Bruce.



geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
Line 79 (original), 79 (patched)


do we want fine level log here?


- Hitesh Khamesra


On June 21, 2017, 10:24 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60106/
> ---
> 
> (Updated June 21, 2017, 10:24 p.m.)
> 
> 
> Review request for geode, Alexander Murmann, Galen O'Sullivan, Hitesh 
> Khamesra, and Brian Rowe.
> 
> 
> Bugs: GEODE-3052
> https://issues.apache.org/jira/browse/GEODE-3052
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> There were four problems that new unit tests hit:
> 1. when recovering a view from disk we were treating it as a definitive 
> (live) view.  I've moved it to a new variable in GMSLocator and set its 
> viewId to -1.  At the same time I set the initial GMSJoinLeave 
> SearchState.viewId to -100 so it will be overridden by the one returned by 
> the locator.  These changes allow GmsJoinLeave to know that the potential 
> coordinator is from a recovered view.
> 2. when trying to join with a recovered view GMSJoinLeave.join() was giving 
> up after the second ID in the view and becoming the coordinator.  It needs to 
> keep trying until the list is exhausted, and it shouldn't sleep between 
> attempts.
> 3. GMSLocator wasn't returning registrants for use in 
> findCoordinatorFromView().  This was causing it to choose itself as the 
> coordinator instead of using registrant sort order and choosing a different 
> registrant as the coordinator.
> 4. During concurrent startup GMSLocator didn't know when the decision was 
> made to become coordinator.  It is now notified of this decision and 
> processRequest() uses this flag to have it override anything in the 
> registrants set or in the recovered view.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/NetView.java
>  26b03276b0abbf6210a5602a8c551abe38edc261 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSUtil.java
>  c6bef571134c6444a297cc8fe0bb0b7eb95f41f4 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/interfaces/Locator.java
>  c5fdf45411581a36feca220e14a0551f3197d368 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/FindCoordinatorResponse.java
>  edfaf625e6c652f46d9323c1116791f1c69fda59 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/GMSLocator.java
>  93fa9dab4ec2c8e43fc41cfd3b8ad986f96cf00f 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  8abcc456e42ad00a558a93f87bd3ae74ce88d146 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/GMSEncrypt.java
>  c7b1a26b47cf2c913d9de30d6934ad5b3ac49840 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/JGroupsMessenger.java
>  390824eb11a2e72a21d951539c2e03ed8025be82 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
> 7ecca6146f6b7a542ae9864d7fabd48c9794ecac 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorUDPSecurityDUnitTest.java
>  df1d8d1101a5f9d04c402922955a283353aa3b7c 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeaveTestHelper.java
>  19cee066a488198471ebf4093045853e36d5ba78 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/messenger/GMSEncryptJUnitTest.java
>  7f64c670400464aa8e6a73405516bd6e891a006b 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
>  b35270e2d97930cee68d8c54221a04c20dfb96de 
> 
> 
> Diff: https://reviews.apache.org/r/60106/diff/2/
> 
> 
> Testing
> ---
> 
> New unit tests, regression testing 

Review Request 60348: GEODE-3103: GfshRule no longer clutters output

[Jared Stewart]

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

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


Repository: geode


Description
---

- GfshRule writes via a logger rather than StdOut.  This will make it no longer 
clutter precheckin runs or the nightly build.
- Introduce ProcessLogger to capture output from the Gfsh JVM so that tests can 
assert against the output.


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/StatusLocatorRealGfshTest.java
 82ee240539b0190a8698939faa63c696d1e03efb 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/GfshExecution.java
 PRE-CREATION 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/GfshRule.java
 81093778d379d6610b94ee93b180bcc773eb3595 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/GfshScript.java
 3ee1402aa9c390d1bc097e29190010ff1496fca6 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/ProcessLogger.java
 PRE-CREATION 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/StreamGobbler.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/CommandStringBuilder.java
 cfb8a24d250af11723c27d35112f6a5e4fde4568 


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


Testing
---

Precheckin running


Thanks,

Jared Stewart

Review Request 60347: GEODE-3097: GFSH works over HTTP with SSL

[Jared Stewart]

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

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


Repository: geode


Description
---

GEODE-3097: GFSH works over HTTP with SSL


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ShellCommands.java
 2da95a7c3f305aab4e615d4be7b14c19b9b31dbc 
  
geode-core/src/test/java/org/apache/geode/management/ConnectToLocatorSSLDUnitTest.java
 844e0322eecdc93c4d46c546f4df2d278c5f15cd 


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


Testing
---


Thanks,

Jared Stewart

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #592 was successful.
---
Scheduled
1870 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 60278: GEODE-3101 fix local locks not being released in client if the JTA transaction failed due to commit conflict on server in beforeCompletion()

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On June 21, 2017, 5:40 p.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60278/
> ---
> 
> (Updated June 21, 2017, 5:40 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Lynn Gallinat, and Swapnil 
> Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Release the local locks it hold if tx failed on server during beforeCompletion
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tx/ClientTXStateStub.java
>  ded789e 
>   
> geode-core/src/test/java/org/apache/geode/internal/jta/ClientServerJTADUnitTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/60278/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin ongoing.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

[GitHub] geode pull request #588: GEODE-2820: Added awaitlity clause to wait for the ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 60106: GEODE-3052 Restarting 2 locators within 1s of each other causes potential locator split brain

[Hitesh Khamesra]

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




geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/GMSLocator.java
Lines 235 (patched)


we are setting -1 viewid for recorded view while recovery. Thus do we need 
"usingRecoveredView" flag here?


- Hitesh Khamesra


On June 19, 2017, 4:09 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60106/
> ---
> 
> (Updated June 19, 2017, 4:09 p.m.)
> 
> 
> Review request for geode and Hitesh Khamesra.
> 
> 
> Bugs: GEODE-3052
> https://issues.apache.org/jira/browse/GEODE-3052
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> There were four problems that new unit tests hit:
> 1. when recovering a view from disk we were treating it as a definitive 
> (live) view.  I've moved it to a new variable in GMSLocator and set its 
> viewId to -1.  At the same time I set the initial GMSJoinLeave 
> SearchState.viewId to -100 so it will be overridden by the one returned by 
> the locator.  These changes allow GmsJoinLeave to know that the potential 
> coordinator is from a recovered view.
> 2. when trying to join with a recovered view GMSJoinLeave.join() was giving 
> up after the second ID in the view and becoming the coordinator.  It needs to 
> keep trying until the list is exhausted, and it shouldn't sleep between 
> attempts.
> 3. GMSLocator wasn't returning registrants for use in 
> findCoordinatorFromView().  This was causing it to choose itself as the 
> coordinator instead of using registrant sort order and choosing a different 
> registrant as the coordinator.
> 4. During concurrent startup GMSLocator didn't know when the decision was 
> made to become coordinator.  It is now notified of this decision and 
> processRequest() uses this flag to have it override anything in the 
> registrants set or in the recovered view.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/NetView.java
>  26b03276b0abbf6210a5602a8c551abe38edc261 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSUtil.java
>  c6bef571134c6444a297cc8fe0bb0b7eb95f41f4 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/interfaces/Locator.java
>  c5fdf45411581a36feca220e14a0551f3197d368 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/FindCoordinatorResponse.java
>  edfaf625e6c652f46d9323c1116791f1c69fda59 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/GMSLocator.java
>  93fa9dab4ec2c8e43fc41cfd3b8ad986f96cf00f 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  8abcc456e42ad00a558a93f87bd3ae74ce88d146 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/GMSEncrypt.java
>  c7b1a26b47cf2c913d9de30d6934ad5b3ac49840 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/JGroupsMessenger.java
>  390824eb11a2e72a21d951539c2e03ed8025be82 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
> 7ecca6146f6b7a542ae9864d7fabd48c9794ecac 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorUDPSecurityDUnitTest.java
>  df1d8d1101a5f9d04c402922955a283353aa3b7c 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeaveTestHelper.java
>  19cee066a488198471ebf4093045853e36d5ba78 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/messenger/GMSEncryptJUnitTest.java
>  7f64c670400464aa8e6a73405516bd6e891a006b 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
>  b35270e2d97930cee68d8c54221a04c20dfb96de 
> 
> 
> Diff: https://reviews.apache.org/r/60106/diff/2/
> 
> 
> Testing
> ---
> 
> New unit tests, regression testing (under way), precheckin (under way)
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

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

[Lynn Hughes-Godfrey]

We've been seeing this since mid-May from Jenkins ... is someone following
up on this, or should I open a new ticket for this?

 [error 2017/06/20 19:06:27.924 UTC 
tid=0x13] failed setting interface to /127.0.1.1: java.net.SocketException:
bad argument for IP_MULTICAST_IF: address not bound to any interface
java.net.SocketException: bad argument for IP_MULTICAST_IF: address not
bound to any interface

On Tue, Jun 20, 2017 at 3:22 PM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See  redirect?page=changes>
>
> Changes:
>
> [jdeppe] GEODE-3071: Provide capability to parallelize distributedTests
>
> [jdeppe] Remove debug println
>
> [jdeppe] GEODE_3071: Add Apache license header
>
> [jdeppe] GEODE-3071: Pull config of docker volumes into top level script
> so that
>
> [khowe] GEODE-2601: Fixing banner being logged twice during locator
> startup (now
>
> [khowe] GEODE-2601: Fixing banner being logged twice during locator
> startup.
>
> [khowe] GEODE-2601: Updated based on feedback
>
> [jiliao] GEODE-3092: fix specifiedDefaultValue for cacheLoader and
> cacheWriter
>
> [dbarnes] Update geode-book/README.md
>
> [Anil] GEODE-3091: remove empty method
>
> [jiliao] GEODE-3056: fix the message for invalid partition-resolver
>
> --
> [...truncated 970.05 KB...]
> at org.apache.geode.distributed.internal.DistributionManager.
> create(DistributionManager.java:573)
> at org.apache.geode.distributed.internal.
> InternalDistributedSystem.initialize(InternalDistributedSystem.java:736)
> at org.apache.geode.distributed.internal.
> InternalDistributedSystem.newInstance(InternalDistributedSystem.java:350)
> at org.apache.geode.distributed.internal.
> InternalDistributedSystem.newInstance(InternalDistributedSystem.java:336)
> at org.apache.geode.distributed.internal.
> InternalDistributedSystem.newInstance(InternalDistributedSystem.java:330)
> at org.apache.geode.distributed.DistributedSystem.connect(
> DistributedSystem.java:205)
> at org.apache.geode.distributed.internal.InternalLocator.
> startDistributedSystem(InternalLocator.java:695)
> at org.apache.geode.distributed.internal.InternalLocator.
> startLocator(InternalLocator.java:325)
> at org.apache.geode.distributed.Locator.startLocator(Locator.
> java:253)
> at org.apache.geode.distributed.Locator.startLocatorAndDS(
> Locator.java:202)
> at org.apache.geode.cache.client.internal.LocatorTestBase.
> startLocator(LocatorTestBase.java:131)
> at org.apache.geode.cache.client.internal.LocatorTestBase$2.
> run(LocatorTestBase.java:142)
> 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:498)
> at hydra.MethExecutor.executeObject(MethExecutor.java:245)
> at org.apache.geode.test.dunit.standalone.RemoteDUnitVM.
> executeMethodOnObject(RemoteDUnitVM.java:70)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(
> UnicastServerRef.java:346)
> 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$0(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:748)
>
> org.apache.geode.cache.wan.GatewayReceiverAutoConnectionSourceDUnitTest >
> testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> 
> ---
> Found suspect string in log4j at line 359
>
> 

Review Request 60312: GEODE-2804 Cache InetAddress if configure host as ip string.

[Hitesh Khamesra]

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

Review request for geode, Alexander Murmann, Bruce Schuchardt, and Galen 
O'Sullivan.


Repository: geode


Description
---

GEODE-2804 Cache InetAddress if configure host as ip string.

1. We keep configure host string in HostAddress class
2. We reuse InetsocketAddress if it is ipString.
3. Client has logic to retry thus we keep InetsocketAddress even if 
   it is not ip string.

GEODE-3017 IPv6 issue on windows. Above changes fixed this issue.

GEODE-2940 Now we don't validate configure host string on start. As
there is possibility that host may not available.

1. Earlier wan config were failing because of that. Now we just keep
those configure host string. And try this later.

Added unit tests for it.


Diffs
-

  geode-assembly/build.gradle 39bb542 
  geode-assembly/src/test/resources/expected_jars.txt 6260167 
  geode-core/build.gradle 7f34b4a 
  
geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
 c1bfc93 
  
geode-core/src/main/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImpl.java
 070451c 
  geode-core/src/main/java/org/apache/geode/cache/client/internal/PoolImpl.java 
3ded54a 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
 01c6157 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
 1572355 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSUtil.java
 c6bef57 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/locator/GMSLocator.java
 93fa9da 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
 84d42cf 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/HostAddress.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpClient.java
 e9476b5 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
 5ab1bed 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
 1dc2fd1 
  
geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
 4f4881f 
  geode-core/src/main/java/org/apache/geode/internal/cache/PoolFactoryImpl.java 
d4fdbd0 
  
geode-core/src/test/java/org/apache/geode/cache/client/internal/AutoConnectionSourceDUnitTest.java
 789d326 
  
geode-core/src/test/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImplJUnitTest.java
 9169904 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
 9f6c5fb 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/StartupMessageDataJUnitTest.java
 9d63050 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
 a31fa8d 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
6a6e0c1 
  
geode-wan/src/main/java/org/apache/geode/cache/client/internal/locator/wan/LocatorDiscovery.java
 f5a8fcf 
  
geode-wan/src/main/java/org/apache/geode/cache/client/internal/locator/wan/LocatorMembershipListenerImpl.java
 d6d5d7c 
  
geode-wan/src/main/java/org/apache/geode/internal/cache/wan/AbstractRemoteGatewaySender.java
 dbc2cc6 
  
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/misc/WanAutoDiscoveryDUnitTest.java
 6d75064 
  gradle/dependency-versions.properties 183dafc 


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


Testing
---


Thanks,

Hitesh Khamesra

[GitHub] geode issue #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/596
  
Precheckin running.


---
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 #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[PurelyApplied]

GitHub user PurelyApplied opened a pull request:

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

GEODE-2920 - GEODE-2925: Finer Grained Security

Due to the size of this commit and for your convenience of review, I have 
not yet squashed my commits.  Do note that I have not individually tested each 
individual commit for stability and each internal commit is meant only for ease 
of review.

The commit message to be included in the final, squashed version of this PR 
is present in the `8fe19ca`... commit, and reproduced below.

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

-

This commit represents the actual Finer Grained Security changes.
GEODE-2920 - GEODE-2925: Migration of security from DATA:MANAGE
* DATA:MANAGE -> CLUSTER:MANAGE
*
* configure pdx
* import cluster-configuration
* LockServiceMXBean.becomeLockGrantor
*
* DATA:MANAGE -> CLUSTER:MANAGE:DISK
*
* compact disk-store
* create disk-store
* destroy disk-store
* revoke missing-disk-store
* DiskStoreMXBean.forceRoll
* DiskStoreMXBean.forceCompaction
* DiskStoreMXBean.flush
* DiskStoreMXBean.setDiskUsageWarningPercentage
* DiskStoreMXBean.setDiskUsageCriticalPercentage
* DistributedSystemMXBean.revokeMissingDiskStores
* MemberMXBean.compactAllDistStores
*
* DATA:MANAGE -> CLUSTER:MANAGE:GATEWAY
*
* create gateway-receiver
* create gateway-sender
* destroy gateway-sender
* load-balance gateway-sender
* pause gateway-sender
* resume gateway-sender
* start gateway-receiver
* start gateway-sender
* stop gateway-receiver
* stop gateway-sender
* GatewayReceiverMXBean.start
* GatewayReceiverMXBean.stop
* GatewaySenderMXBean.start
* GatewaySenderMXBean.stop
* GatewaySenderMXBean.pause
* GatewaySenderMXBean.resume
* GatewaySenderMXBean.rebalance
*
* DATA:MANAGE -> CLUSTER:MANAGE:JAR
*
* create async-event-queue (Requires CLUSTER:WRITE:DISK if persistent)
* destroy function
* undeploy
*
* DATA:MANAGE -> CLUSTER:MANAGE:QUERY
*
* clear defined indexes
* close durable-client
* close durable-cq
* create defined indexes
* stop continuous-query
* CacheServerMXBean.closeAllContinuousQuery
* CacheServerMXBean.closeContinuousQuery
* DistributedSystemMXBean.setQueryResultSetLimit
* DistributedSystemMXBean.setQueryCollectionsDepth
*
* DATA:READ -> CLUSTER:READ
*
* list region
*
* DATA:MANAGE -> [None]
*
* pdx rename
*
* DATA:READ -> DATA:READ and CLUSTER:WRITE:DISK
*
* backup disk-store
* DistributedSystemMXBean.backupAllMembers
*
* DATA:MANAGE:RegionName -> CLUSTER:MANAGE:QUERY
*
* create index
* create lucene index (also requires CLUSTER:WRITE:DISK)
* define index
* destroy lucene index
*
* DATA:MANAGE, DATA:WRITE, CLUSTER:MANAGE, and CLUSTER:WRITE -> 
CLUSTER:MANAGE:JAR
*
* deploy
*
* DATA:MANAGE or DATA:MANAGE:RegionName -> CLUSTER:MANAGE:QUERY
*
* destroy index
*
* CLUSTER:READ -> CLUSTER:READ:QUERY
*
* describe lucene index
* list index
* list lucene indexes
*
* DATA:WRITE -> DATA:READ:Region
*
* search lucene index
*
* DATA:MANAGE -> DATA:MANAGE and CLUSTER:WRITE:DISK if persistent
*
* create region

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

$ git pull https://github.com/PurelyApplied/geode geode-2924

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

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


commit 8b14112094fd49bfc7638cc952f8d322d5bd50e7
Author: Patrick Rhomberg 
Date:   2017-06-21T17:51:32Z

For ease of viewing, this commit covers all necessary imports.

commit 8fe19ca6ff3e51aed601537afb8e23c3e85569a1
Author: Patrick Rhomberg 
Date:   2017-06-21T18:59:13Z

This commit represents the actual Finer Grained Security changes.

GEODE-2920 - GEODE-2925: Migration of security from DATA:MANAGE
* DATA:MANAGE -> CLUSTER:MANAGE
*
* configure pdx
* import cluster-configuration
* LockServiceMXBean.becomeLockGrantor
*
* DATA:MANAGE -> CLUSTER:MANAGE:DISK
*
* compact disk-store
* create disk-store
* destroy disk-store
* revoke missing-disk-store
* DiskStoreMXBean.forceRoll
* DiskStoreMXBean.forceCompaction
* DiskStoreMXBean.flush
* DiskStoreMXBean.setDiskUsageWarningPercentage
* DiskStoreMXBean.setDiskUsageCriticalPercentage
* DistributedSystemMXBean.revokeMissingDiskStores
* MemberMXBean.compactAllDistStores
*
* DATA:MANAGE -> CLUSTER:MANAGE:GATEWAY
*
* 

[GitHub] geode issue #586: GEODE-3075: initial flow adding the new client protocol to...

[galen-pivotal]

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/586
  
@bschuchardt Was that the only failure? It looks like another test had set 
`mcast-port` to a non-zero value and failed to clean up the environment

I'm rerunning precheckin; will continue working on top of this branch and 
hopefully this passes. If that's the only failure, I would think it should be 
safe to merge with the one-line added change.


---
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 #576: Geode 2920, 2921, 2922, 2924

[PurelyApplied]

Github user PurelyApplied closed the pull request at:

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


---
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 #576: Geode 2920, 2921, 2922, 2924

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/576
  
Closing this PR to reopen the finalized form.


---
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: Need information about FunctionStatistics

[Kirk Lund]

We had plans to create a new Statistics API [1] for people to use to
subscribe to stats and expose them on custom user-implemented MBeans. The
use case matches what you want to do. Unfortunately without the completion
of that new API, what you're trying to do isn't going to be easy and would
require changing Geode itself.

Part of the new Statistics API was implemented around GemFire 7.0 timeframe
and currently exists as an internal (non-user) API which the existing Geode
MXBeans use to expose stats. The partial API is in
org.apache.geode.internal.statistics package and includes StatisticsMonitor
(and its sub-classes), StatisticId,
StatisticsListener, StatisticsNotification, StatMonitorNotifier.

[1] https://cwiki.apache.org/confluence/display/GEODE/Statistics+API

On Wed, Jun 21, 2017 at 12:14 PM, Barry Oglesby  wrote:

> This will be a nice addition.
>
> I'm not sure I would create the MBeans for all the registered functions at
> once. You'll have to deal with functions being registered on the fly or
> after you've called handleFunctionCreation. I think I would change the
> handleFunctionCreation to take a Function or FunctionStats (depending on
> when you call it) and create the MBean for each function individually. I
> can see a couple potential places to call this method whenever each
> function is registered. One would be FunctionService.registerFunction or
> FunctionServiceManager registerFunction. That could create a placeholder
> MBean. Then when the FunctionStats are created later, they could be added
> to the appropriate MBean. You don't show when / how you're adding the
> FunctionStats to the MBean, but that has to be done somewhere. It might be
> easier to call the handleFunctionCreation in InternalDistributedSystem
> getFunctionStats when the FunctionStats are created. I'm not sure whether
> you need the actual Function instance in the MBean. I guess I would look
> into those places to add the handleFunctionCreation.
>
>
> Thanks,
> Barry Oglesby
>
>
> On Wed, Jun 21, 2017 at 7:36 AM, Dinesh Akhand 
> wrote:
>
> > Hi ,
> >
> >
> >
> > I have registered all function stats to JMX by creating new bean.
> >
> > But need to know what Is the correct place register this bean.
> >
> >
> >
> > I did like this :
> >
> >
> >
> > public void handleFunctionCreation() throws ManagementException {
> >
> >   Map functionMap =  FunctionService.
> > getRegisteredFunctions();
> >
> >   logger.info("akhand :functionMap:"+functionMap.size());
> >
> >   for(String funid :functionMap.keySet())
> >
> >  {
> >
> > Function functionDetail= functionMap.get(funid);
> >
> >   FunctionStatsMBeanBridge functionStatsMBeanBridge = new
> > FunctionStatsMBeanBridge(functionDetail,cacheImpl, service);
> >
> >   FunctionStatsMXBean functionBean = new FunctionStatsMBean(
> > functionStatsMBeanBridge);
> >
> >   ObjectName senderObjectName = MBeanJMXAdapter.
> > getFunctionStatsMBeanName(
> >
> >   cacheImpl.getDistributedSystem().
> getDistributedMember(),
> > funid);
> >
> >   ObjectName changedFunctionMBeanName =
> > service.registerInternalMBean(functionBean, senderObjectName);
> >
> >
> >
> >   service.federate(changedFunctionMBeanName,
> > FunctionStatsMXBean.class, true);
> >
> >  }
> >
> > }
> >
> >
> >
> > But from where I need to call this method .
> >
> > Currently I called above method from ManagementListener.java
> >
> >   case CACHE_SERVER_START:
> >
> > CacheServer startedServer = (CacheServer) resource;
> >
> > adapter.handleCacheServerStart(startedServer);
> >
> > adapter.handleFunctionCreation();
> >
> > break;
> >
> >
> >
> > Please suggest.
> >
> >
> >
> > Thanks,
> >
> > Dinesh Akhand
> >
> >
> >
> >
> >
> >
> >
> > -Original Message-
> > From: Dinesh Akhand
> > Sent: Friday, June 9, 2017 6:44 PM
> > To: dev@geode.apache.org; bogle...@pivotal.io
> > Subject: RE: Need information about FunctionStatistics
> >
> >
> >
> > Hi Team,
> >
> >
> >
> > Problem Solved ,
> >
> >
> >
> > Function Stats works fine if function is associated with JVM . else it
> > will display 0 .
> >
> >
> >
> > Thanks,
> >
> > Dinesh Akhand
> >
> >
> >
> > From: Dinesh Akhand
> >
> > Sent: Friday, June 9, 2017 4:34 PM
> >
> > To: dev@geode.apache.org; 'bogle...@pivotal.io' 
> >
> > Subject: RE: Need information about FunctionStatistics
> >
> >
> >
> >
> >
> > Hi Barry,
> >
> >
> >
> >
> >
> >
> >
> > Yes , I can see the function statics in VSD  but looks like
> >
> >
> >
> >
> >
> >
> >
> > All the stats are 0 .  not even for single function stats are correct .
> >
> >
> >
> >
> >
> >
> >
> >FunctionExecution, 2265, FunctionServiceStatistics: "2017/06/07
> > 12:11:09.201 IDT" samples=502
> >
> >
> >
> >   functionExecutionsCompleted operations/sec: samples=501 min=0 

Re: Review Request 60217: GEODE-2995: adding in protocol handler for protobuf messages

[Galen O'Sullivan]

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


Ship it!




Ship It!

- Galen O'Sullivan


On June 21, 2017, 7:01 p.m., Brian Rowe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60217/
> ---
> 
> (Updated June 21, 2017, 7:01 p.m.)
> 
> 
> Review request for geode, Alexander Murmann, Bruce Schuchardt, Galen 
> O'Sullivan, Hitesh Khamesra, and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This change adds a new module for handling client stresms encoded using the 
> new ProtoBuf protocol.  At the top level this can be integrated by passing in 
> the input/output streams and cache reference to the ProtobufStreamProcessor.  
> This will decode the message and ultimately dispatch it to an operation 
> specific handler which will call back into the passed cache object.  Note 
> that this not currently hooked up to geode at all, GEODE-3075 is tracking the 
> work needed to hook this up at that level.
> 
> This change mainly contains the plumbing and encoding/decoding logic, but 
> also contain the Get operation handler as a proof of concept.  Future work 
> will be needed to handle other types of operations.
> 
> 
> Diffs
> -
> 
>   geode-protobuf/build.gradle PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/exception/InvalidProtocolMessageException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/OperationHandler.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/OperationsHandlerRegistry.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/exception/OperationHandlerAlreadyRegisteredException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/exception/OperationHandlerNotRegisteredException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/EncodingTypeTranslator.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufOpsProcessor.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufSerializationService.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufStreamProcessor.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufUtilities.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/operations/GetRequestOperationHandler.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/serializer/ProtobufProtocolSerializer.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/serializer/ProtocolSerializer.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/SerializationService.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/SerializationType.java
>  PRE-CREATION 
>   geode-protobuf/src/main/java/org/apache/geode/serialization/TypeCodec.java 
> PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/BinaryCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/BooleanCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/ByteCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/DoubleCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/FloatCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/IntCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/JSONCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/LongCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/ShortCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/StringCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/exception/TypeEncodingException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/exception/UnsupportedEncodingTypeException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/registry/SerializationCodecRegistry.java
>  PRE-CREATION 
>   
> 

Re: Need information about FunctionStatistics

[Barry Oglesby]

This will be a nice addition.

I'm not sure I would create the MBeans for all the registered functions at
once. You'll have to deal with functions being registered on the fly or
after you've called handleFunctionCreation. I think I would change the
handleFunctionCreation to take a Function or FunctionStats (depending on
when you call it) and create the MBean for each function individually. I
can see a couple potential places to call this method whenever each
function is registered. One would be FunctionService.registerFunction or
FunctionServiceManager registerFunction. That could create a placeholder
MBean. Then when the FunctionStats are created later, they could be added
to the appropriate MBean. You don't show when / how you're adding the
FunctionStats to the MBean, but that has to be done somewhere. It might be
easier to call the handleFunctionCreation in InternalDistributedSystem
getFunctionStats when the FunctionStats are created. I'm not sure whether
you need the actual Function instance in the MBean. I guess I would look
into those places to add the handleFunctionCreation.


Thanks,
Barry Oglesby


On Wed, Jun 21, 2017 at 7:36 AM, Dinesh Akhand  wrote:

> Hi ,
>
>
>
> I have registered all function stats to JMX by creating new bean.
>
> But need to know what Is the correct place register this bean.
>
>
>
> I did like this :
>
>
>
> public void handleFunctionCreation() throws ManagementException {
>
>   Map functionMap =  FunctionService.
> getRegisteredFunctions();
>
>   logger.info("akhand :functionMap:"+functionMap.size());
>
>   for(String funid :functionMap.keySet())
>
>  {
>
> Function functionDetail= functionMap.get(funid);
>
>   FunctionStatsMBeanBridge functionStatsMBeanBridge = new
> FunctionStatsMBeanBridge(functionDetail,cacheImpl, service);
>
>   FunctionStatsMXBean functionBean = new FunctionStatsMBean(
> functionStatsMBeanBridge);
>
>   ObjectName senderObjectName = MBeanJMXAdapter.
> getFunctionStatsMBeanName(
>
>   cacheImpl.getDistributedSystem().getDistributedMember(),
> funid);
>
>   ObjectName changedFunctionMBeanName =
> service.registerInternalMBean(functionBean, senderObjectName);
>
>
>
>   service.federate(changedFunctionMBeanName,
> FunctionStatsMXBean.class, true);
>
>  }
>
> }
>
>
>
> But from where I need to call this method .
>
> Currently I called above method from ManagementListener.java
>
>   case CACHE_SERVER_START:
>
> CacheServer startedServer = (CacheServer) resource;
>
> adapter.handleCacheServerStart(startedServer);
>
> adapter.handleFunctionCreation();
>
> break;
>
>
>
> Please suggest.
>
>
>
> Thanks,
>
> Dinesh Akhand
>
>
>
>
>
>
>
> -Original Message-
> From: Dinesh Akhand
> Sent: Friday, June 9, 2017 6:44 PM
> To: dev@geode.apache.org; bogle...@pivotal.io
> Subject: RE: Need information about FunctionStatistics
>
>
>
> Hi Team,
>
>
>
> Problem Solved ,
>
>
>
> Function Stats works fine if function is associated with JVM . else it
> will display 0 .
>
>
>
> Thanks,
>
> Dinesh Akhand
>
>
>
> From: Dinesh Akhand
>
> Sent: Friday, June 9, 2017 4:34 PM
>
> To: dev@geode.apache.org; 'bogle...@pivotal.io' 
>
> Subject: RE: Need information about FunctionStatistics
>
>
>
>
>
> Hi Barry,
>
>
>
>
>
>
>
> Yes , I can see the function statics in VSD  but looks like
>
>
>
>
>
>
>
> All the stats are 0 .  not even for single function stats are correct .
>
>
>
>
>
>
>
>FunctionExecution, 2265, FunctionServiceStatistics: "2017/06/07
> 12:11:09.201 IDT" samples=502
>
>
>
>   functionExecutionsCompleted operations/sec: samples=501 min=0 max=0.2
> average=0 stddev=0.01 last=0
>
>
>
>   functionExecutionsCompletedProcessingTime nanoseconds/sec: samples=501
> min=0 max=190219.8 average=379.68 stddev=8498.39 last=0
>
>
>
>   functionExecutionsRunning operations: samples=502 min=0 max=0 average=0
> stddev=0 last=0
>
>
>
>   resultsSentToResultCollector operations/sec: samples=501 min=0 max=0.2
> average=0 stddev=0.01 last=0
>
>
>
>   resultsReceived operations/sec: samples=501 min=0 max=0 average=0
> stddev=0 last=0
>
>
>
>   functionExecutionCalls operations/sec: samples=501 min=0 max=0.2
> average=0 stddev=0.01 last=0
>
>
>
>   functionExecutionsHasResultCompletedProcessingTime nanoseconds/sec:
> samples=501 min=0 max=190219.8 average=379.68 stddev=8498.39 last=0
>
>
>
>   functionExecutionsHasResultRunning operations: samples=502 min=0 max=0
> average=0 stddev=0 last=0
>
>
>
>   functionExecutionsExceptions operations/sec: samples=501 min=0 max=0
> average=0 stddev=0 last=0
>
>
>
>
>
>
>
> Can you please confirm function stats values are correct in your case.
>
>
>
>
>
>
>
> Thanks,
>
>
>
> Dinesh Akhand
>
>
>
>
>
>
>
> -Original Message-
>
> From: Barry Oglesby [mailto:bogle...@pivotal.io ]
>
> 

Re: Review Request 60217: GEODE-2995: adding in protocol handler for protobuf messages

[Hitesh Khamesra]

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


Ship it!




Ship It!

- Hitesh Khamesra


On June 21, 2017, 7:01 p.m., Brian Rowe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60217/
> ---
> 
> (Updated June 21, 2017, 7:01 p.m.)
> 
> 
> Review request for geode, Alexander Murmann, Bruce Schuchardt, Galen 
> O'Sullivan, Hitesh Khamesra, and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This change adds a new module for handling client stresms encoded using the 
> new ProtoBuf protocol.  At the top level this can be integrated by passing in 
> the input/output streams and cache reference to the ProtobufStreamProcessor.  
> This will decode the message and ultimately dispatch it to an operation 
> specific handler which will call back into the passed cache object.  Note 
> that this not currently hooked up to geode at all, GEODE-3075 is tracking the 
> work needed to hook this up at that level.
> 
> This change mainly contains the plumbing and encoding/decoding logic, but 
> also contain the Get operation handler as a proof of concept.  Future work 
> will be needed to handle other types of operations.
> 
> 
> Diffs
> -
> 
>   geode-protobuf/build.gradle PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/exception/InvalidProtocolMessageException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/OperationHandler.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/OperationsHandlerRegistry.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/exception/OperationHandlerAlreadyRegisteredException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/exception/OperationHandlerNotRegisteredException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/EncodingTypeTranslator.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufOpsProcessor.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufSerializationService.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufStreamProcessor.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufUtilities.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/operations/GetRequestOperationHandler.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/serializer/ProtobufProtocolSerializer.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/serializer/ProtocolSerializer.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/SerializationService.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/SerializationType.java
>  PRE-CREATION 
>   geode-protobuf/src/main/java/org/apache/geode/serialization/TypeCodec.java 
> PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/BinaryCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/BooleanCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/ByteCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/DoubleCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/FloatCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/IntCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/JSONCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/LongCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/ShortCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/StringCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/exception/TypeEncodingException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/exception/UnsupportedEncodingTypeException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/registry/SerializationCodecRegistry.java
>  PRE-CREATION 
>   
> 

Re: Review Request 60217: GEODE-2995: adding in protocol handler for protobuf messages

[Brian Rowe]

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

(Updated June 21, 2017, 7:01 p.m.)


Review request for geode, Alexander Murmann, Bruce Schuchardt, Galen 
O'Sullivan, Hitesh Khamesra, and Udo Kohlmeyer.


Repository: geode


Description
---

This change adds a new module for handling client stresms encoded using the new 
ProtoBuf protocol.  At the top level this can be integrated by passing in the 
input/output streams and cache reference to the ProtobufStreamProcessor.  This 
will decode the message and ultimately dispatch it to an operation specific 
handler which will call back into the passed cache object.  Note that this not 
currently hooked up to geode at all, GEODE-3075 is tracking the work needed to 
hook this up at that level.

This change mainly contains the plumbing and encoding/decoding logic, but also 
contain the Get operation handler as a proof of concept.  Future work will be 
needed to handle other types of operations.


Diffs (updated)
-

  geode-protobuf/build.gradle PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/protocol/exception/InvalidProtocolMessageException.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/protocol/operations/OperationHandler.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/OperationsHandlerRegistry.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/exception/OperationHandlerAlreadyRegisteredException.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/exception/OperationHandlerNotRegisteredException.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/EncodingTypeTranslator.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufOpsProcessor.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufSerializationService.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufStreamProcessor.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufUtilities.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/operations/GetRequestOperationHandler.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/serializer/ProtobufProtocolSerializer.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/protocol/serializer/ProtocolSerializer.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/SerializationService.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/SerializationType.java
 PRE-CREATION 
  geode-protobuf/src/main/java/org/apache/geode/serialization/TypeCodec.java 
PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/codec/BinaryCodec.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/codec/BooleanCodec.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/codec/ByteCodec.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/codec/DoubleCodec.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/codec/FloatCodec.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/codec/IntCodec.java 
PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/codec/JSONCodec.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/codec/LongCodec.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/codec/ShortCodec.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/codec/StringCodec.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/exception/TypeEncodingException.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/exception/UnsupportedEncodingTypeException.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/registry/SerializationCodecRegistry.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/registry/exception/CodecAlreadyRegisteredForTypeException.java
 PRE-CREATION 
  
geode-protobuf/src/main/java/org/apache/geode/serialization/registry/exception/CodecNotRegisteredForTypeException.java
 PRE-CREATION 
  geode-protobuf/src/main/proto/basicTypes.proto PRE-CREATION 
  geode-protobuf/src/main/proto/clientProtocol.proto PRE-CREATION 
  geode-protobuf/src/main/proto/region_API.proto PRE-CREATION 
  geode-protobuf/src/main/proto/server_API.proto PRE-CREATION 
  

[GitHub] geode pull request #589: GEODE-393: Providing cache for FunctionContext

[jinmeiliao]

Github user jinmeiliao commented on a diff in the pull request:

https://github.com/apache/geode/pull/589#discussion_r123332996
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/execute/FunctionContextImpl.java
 ---
@@ -37,20 +38,25 @@
 
   private String functionId = null;
 
+  private Cache cache = null;
+
   private ResultSender resultSender = null;
 
   private final boolean isPossDup;
 
   public FunctionContextImpl(final String functionId, final Object args,
   ResultSender resultSender) {
-this.functionId = functionId;
-this.args = args;
-this.resultSender = resultSender;
-this.isPossDup = false;
+this(null, functionId, args, resultSender, false);
+  }
+
+  public FunctionContextImpl(final Cache cache, final String functionId, 
final Object args,
+  ResultSender resultSender) {
+this(cache, functionId, args, resultSender, false);
   }
 
-  public FunctionContextImpl(final String functionId, final Object args, 
ResultSender resultSender,
-  boolean isPossibleDuplicate) {
+  public FunctionContextImpl(final Cache cache, final String functionId, 
final Object args,
+  ResultSender resultSender, boolean isPossibleDuplicate) {
--- End diff --

this could still have have cache end up being null if user did not create 
the FunctionContextImpl with a cache, either pass in null, or use the other 
non-cache constructor. It would be good to add a check here:
if(cache==null){
  cache = GemfireCacheImpl.getExisting();
}


---
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 #578: GEODE-1958: Removing/deprecating PasswordUtil

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: Query for JMX "Async Event Queue properties"

[Barry Oglesby]

I don't see that OR clause on Geode develop. What version of Geode are you
using?

In any event, the JMX MBeans are registered using a ResourceEventsListener
called ManagementListener. That listener is invoked by handleResourceEvent
calls in GemFireCacheImpl for a bunch of different events including region
creation. There isn't any other property that could be set to create the
MBean for that region.

Rather than test the region name in that OR clause, a slightly better way
to implement that would be:

if (!region.isInternalRegion()
|| region.isUsedForParallelGatewaySenderQueue()
|| region.isUsedForSerialGatewaySenderQueue()) {


btw - the MBean should be removed if the region is destroyed. The
LocalRegion recursiveDestroyRegion and basicDestroyRegion methods contain
code like this that should also be modified like above:

if (!region.isInternalRegion()) {
InternalDistributedSystem system =
region.cache.getInternalDistributedSystem();
system.handleResourceEvent(ResourceEvent.REGION_REMOVE, region);
}


Thanks,
Barry Oglesby


On Tue, Jun 20, 2017 at 6:33 AM, Dinesh Akhand  wrote:

> Hi Barry,
>
>
>
> Looks like things are already implemented in geode:
>
>
>
> Class : GemFireCacheImpl
>
>
>
> if (!rgn.isInternalRegion() || 
> rgn.getFullPath().contains("GATEWAY_SENDER_QUEUE"))
> {
>
>   system.handleResourceEvent(ResourceEvent.REGION_CREATE, rgn);
>
> }
>
>
>
> Above code solved my problem .  Async Queue Partition region visible in
> JMX.
>
>
>
> But above code looks like hack in existing code.  Is this fix can we take
> and go ahead because in our requirement we need to show all internal
> partition region.
>
>
>
> Or can we define some property in .properties files to enable stats in jmx
> for internal region?.
>
>
>
> Thanks,
>
> Dinesh Akhand
>
>
>
>
>
> -Original Message-
> From: Barry Oglesby [mailto:bogle...@pivotal.io]
> Sent: Saturday, June 17, 2017 2:14 AM
> To: dev@geode.apache.org
> Subject: Re: Query for JMX "Async Event Queue properties"
>
>
>
> The AsynceEventQueueMBean is monitoring the AsyncEventQueueStats not the
> PartitionedRegionStats. And, actually, the only stat being monitored by
> that MBean is the eventQueueSize stat. The parallel AsyncEventQueue creates
> a colocated PartitionedRegion under the covers, and the stats for that PR
> are the PartitionedRegionStats you referenced. There isn't currently any
> JMX support for those PartitionedRegionStats.
>
>
>
> Are you looking to add support for those PartitionedRegionStats to the
> AsynceEventQueueMBean? If so, I guess there are a few ways to do. The first
> would be to find the underlying PartitionedRegion for the parallel
> AsyncEventQueue, add its PartitionedRegionStats to the
> AsyncEventQueueMBeanBridge's monitor and reference the appropriate one(s)
> (in your case dataStoreBytesInUse). Another would be to actually create an
> MBean for that internal PartitionedRegion.
>
>
>
> Both of these would only be applicable for a parallel AsyncEventQueue.
>
> Serial AsyncEventQueues don't create a PartitionedRegion.
>
>
>
>
>
> Thanks,
>
> Barry Oglesby
>
>
>
>
>
> On Fri, Jun 16, 2017 at 5:38 AM, Dinesh Akhand  > wrote:
>
>
>
> > Hi Team
>
> >
>
> > Regarding the following metrics:
>
> >
>
> > /AsyncEventQueue_XYZ_PARALLEL_GATEWAY_SENDER_QUEUE:
> PartitionedRegionStats.
>
> > dataStoreEntryCount
>
> > /AsyncEventQueue_XYZ_PARALLEL_GATEWAY_SENDER_QUEUE:
> PartitionedRegionStats.
>
> > dataStoreBytesInUse
>
> >
>
> >
>
> > I found only count for async queue in JMX , it called here
>
> > EventQueueSize = PartitionedRegionStats.dataStoreEntryCount
>
> >
>
> > /** AsyncEventQueue Stats **/
>
> >   public static final String ASYNCEVENTQUEUE_EVENTS_QUEUE_SIZE =
>
> > "eventQueueSize"
>
> >
>
> > we having Missing  PartitionedRegionStats.dataStoreBytesInUse in JMX
>
> > for Async Qeueue.
>
> >
>
> > Can you help me , which property I need to map for it.
>
> >
>
> > 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 <
>
> > 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 <
> https://www.amdocs.com/about/email-disclaimer>
>

Review Request 60278: GEODE-3101 fix local locks not being released in client if the JTA transaction failed due to commit conflict on server in beforeCompletion()

[Eric Shu]

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

Review request for geode, anilkumar gingade, Lynn Gallinat, and Swapnil 
Bawaskar.


Repository: geode


Description
---

Release the local locks it hold if tx failed on server during beforeCompletion


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/tx/ClientTXStateStub.java
 ded789e 
  
geode-core/src/test/java/org/apache/geode/internal/jta/ClientServerJTADUnitTest.java
 PRE-CREATION 


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


Testing
---

precheckin ongoing.


Thanks,

Eric Shu

Re: Review Request 60217: GEODE-2995: adding in protocol handler for protobuf messages

[Hitesh Khamesra]

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




geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/EncodingTypeTranslator.java
Lines 56 (patched)


How about having map of "class vs Id"?



geode-protobuf/src/main/java/org/apache/geode/serialization/codec/BooleanCodec.java
Lines 29 (patched)


How about keeping two byte[] here. One for true and one for false.



geode-protobuf/src/main/java/org/apache/geode/serialization/codec/ByteCodec.java
Lines 24 (patched)


Just return first byte?


- Hitesh Khamesra


On June 21, 2017, 12:02 a.m., Brian Rowe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60217/
> ---
> 
> (Updated June 21, 2017, 12:02 a.m.)
> 
> 
> Review request for geode, Alexander Murmann, Bruce Schuchardt, Galen 
> O'Sullivan, Hitesh Khamesra, and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This change adds a new module for handling client stresms encoded using the 
> new ProtoBuf protocol.  At the top level this can be integrated by passing in 
> the input/output streams and cache reference to the ProtobufStreamProcessor.  
> This will decode the message and ultimately dispatch it to an operation 
> specific handler which will call back into the passed cache object.  Note 
> that this not currently hooked up to geode at all, GEODE-3075 is tracking the 
> work needed to hook this up at that level.
> 
> This change mainly contains the plumbing and encoding/decoding logic, but 
> also contain the Get operation handler as a proof of concept.  Future work 
> will be needed to handle other types of operations.
> 
> 
> Diffs
> -
> 
>   geode-protobuf/build.gradle PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/exception/InvalidProtocolMessageException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/OperationHandler.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/OperationsHandlerRegistry.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/exception/OperationHandlerAlreadyRegisteredException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/exception/OperationHandlerNotRegisteredException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/EncodingTypeTranslator.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufOpsProcessor.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufSerializationService.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufStreamProcessor.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufUtilities.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/operations/GetRequestOperationHandler.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/serializer/ProtobufProtocolSerializer.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/serializer/ProtocolSerializer.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/SerializationService.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/SerializationType.java
>  PRE-CREATION 
>   geode-protobuf/src/main/java/org/apache/geode/serialization/TypeCodec.java 
> PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/BinaryCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/BooleanCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/ByteCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/DoubleCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/FloatCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/IntCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/JSONCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/LongCodec.java
>  PRE-CREATION 
>   
> 

Re: Review Request 60217: GEODE-2995: adding in protocol handler for protobuf messages

[Galen O'Sullivan]

> On June 21, 2017, 12:52 a.m., Udo Kohlmeyer wrote:
> > geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/OperationsHandlerRegistry.java
> > Lines 24 (patched)
> > 
> >
> > It is hard to say if it is specific to protobuf. It is the mapping of 
> > an operation in the IDL to the corresponding handler.
> > 
> > Would be interesting to see if we can find a simple way to maintain the 
> > mapping of IDL operation IDs and their OperationHandlers.

protobuf is the IDL... the ID is defined there, which makes me think that the 
IDs are tied to the IDL.

That being said, it's not used anywhere else, so I won't fight fight too hard 
about the naming.


- Galen


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


On June 21, 2017, 12:02 a.m., Brian Rowe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60217/
> ---
> 
> (Updated June 21, 2017, 12:02 a.m.)
> 
> 
> Review request for geode, Alexander Murmann, Bruce Schuchardt, Galen 
> O'Sullivan, Hitesh Khamesra, and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This change adds a new module for handling client stresms encoded using the 
> new ProtoBuf protocol.  At the top level this can be integrated by passing in 
> the input/output streams and cache reference to the ProtobufStreamProcessor.  
> This will decode the message and ultimately dispatch it to an operation 
> specific handler which will call back into the passed cache object.  Note 
> that this not currently hooked up to geode at all, GEODE-3075 is tracking the 
> work needed to hook this up at that level.
> 
> This change mainly contains the plumbing and encoding/decoding logic, but 
> also contain the Get operation handler as a proof of concept.  Future work 
> will be needed to handle other types of operations.
> 
> 
> Diffs
> -
> 
>   geode-protobuf/build.gradle PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/exception/InvalidProtocolMessageException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/OperationHandler.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/OperationsHandlerRegistry.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/exception/OperationHandlerAlreadyRegisteredException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/operations/registry/exception/OperationHandlerNotRegisteredException.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/EncodingTypeTranslator.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufOpsProcessor.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufSerializationService.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufStreamProcessor.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/ProtobufUtilities.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/operations/GetRequestOperationHandler.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/protobuf/serializer/ProtobufProtocolSerializer.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/protocol/serializer/ProtocolSerializer.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/SerializationService.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/SerializationType.java
>  PRE-CREATION 
>   geode-protobuf/src/main/java/org/apache/geode/serialization/TypeCodec.java 
> PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/BinaryCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/BooleanCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/ByteCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/DoubleCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/FloatCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/IntCodec.java
>  PRE-CREATION 
>   
> geode-protobuf/src/main/java/org/apache/geode/serialization/codec/JSONCodec.java
>  

[GitHub] geode issue #586: GEODE-3075: initial flow adding the new client protocol to...

[bschuchardt]

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/586
  
There was a failure in one of the new tests

:geode-core:integrationTest


org.apache.geode.internal.cache.tier.sockets.ServerConnectionFactoryIntegrationTest
 > testNewProtocolHeaderLeadsToNewProtocolServerConnection FAILED
org.apache.geode.GemFireConfigException: The locators attribute can not 
be empty when the mcast-port attribute is non-zero.
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:603)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:350)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:338)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:330)
at 
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:205)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:217)
at 
org.apache.geode.internal.cache.tier.sockets.ServerConnectionFactoryIntegrationTest.testNewProtocolHeaderLeadsToNewProtocolServerConnection(ServerConnectionFactoryIntegrationTest.java:50)



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

Jenkins build is back to normal : Geode-nightly #873

[Apache Jenkins Server]

See 

[GitHub] geode pull request #594: GEODE-2861: Remove dead code

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #595: GEODE-3104 : Modified code to use --include-locator...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 60257: GEODE-3100/GEM-1256: move authorize* call to external SecurityService and have it available in Cache

[Jinmei Liao]

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

(Updated June 21, 2017, 3 p.m.)


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


Repository: geode


Description
---

* move the authorize* call to external SecurityService
* Add getSecurityService() that returns the external SecuritySerfice in Cache
* Add a getCache method in FunctionContext
* Add a test to demonstrate the locking in GetRegionFunction and fix it.

revision 1 is a small changeset that shows all the above. 
revision 2 is a simple rename of the internal SecurityService to 
InternalSecurityService. It touches a lot of files, but the changes are pretty 
autonomous.


Diffs
-

  geode-core/src/main/java/org/apache/geode/cache/Cache.java 
66a3cd8097f8b526d0bd69f3afbd2dc55fa1ac3e 
  geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
9b23f6c1a8ed3449d8a49029d6364f1e989e367c 
  geode-core/src/main/java/org/apache/geode/cache/execute/FunctionContext.java 
74f05c557d3cd7bc05e0389419ef84e17d797bf4 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
 15723557915e2b810270ba58a2195dda8c68 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberFactory.java
 b682d93fd5c4b5340e2c30be72c5572e031e26ed 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberServices.java
 c52ccbc1cc5a293d70b177e38f03dc17c7db 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSMemberFactory.java
 01d99951bc70547fb311f2edbfec8dde1be799f7 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/Services.java
 2d6af1a22644d427ec2d17863cef27a8d8961491 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/auth/GMSAuthenticator.java
 f895b964794f99127f1f0c9564f3f85213e0af22 
  geode-core/src/main/java/org/apache/geode/internal/cache/CacheServerImpl.java 
7d4b6d4988a836854bc2a54a40c761152a635b14 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
5eaa5a4bd237d9d8954ce69323912a6be5139fd0 
  geode-core/src/main/java/org/apache/geode/internal/cache/InternalCache.java 
4c229db09f59deb8d36cc56a532ea0c7d3202977 
  
geode-core/src/main/java/org/apache/geode/internal/cache/execute/FunctionContextImpl.java
 39190f3c9d6ff2403542b729ee8d9c254bf6898f 
  geode-core/src/main/java/org/apache/geode/internal/cache/tier/Command.java 
110d6ef2a59c652cbdc860aad745d123e3b344e5 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/AcceptorImpl.java
 2a8818cefedc8bce415b97b18a32ba083ea2f257 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/BaseCommand.java
 cc78cca048c0215c2086fab80e7834419bdf65a6 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/BaseCommandQuery.java
 184aa36fc5509285001155e20d846cc717544d2f 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/CacheClientProxy.java
 d7e354887b000aad402627acd3b9340d8101e4f8 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/HandShake.java
 32735b9ab17fe9467cea46096bd177902145e4bd 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ServerConnection.java
 947b83652803d7b6af9e6157ba84ba842c5da58e 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ServerHandShakeProcessor.java
 8b896945a8f136b3081df6efec51edec304f3086 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/AddPdxEnum.java
 5a4a07b81b18d33e465bd3aa46ad4232b976b608 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/AddPdxType.java
 cb4b261586a3536cfd5609e627a37cbca7ecf81f 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/ClearRegion.java
 610af436cd96b0663d69915d8a1b37549e4f7bc2 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/ClientReady.java
 ae95caec718141e6567cc57cf1c24193210132fc 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/CloseConnection.java
 ed050bda24bf6896a0494309edbf90e12e759d24 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/CommitCommand.java
 c9987db636d8ff2b01beba1d958d308fdd8430f8 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/ContainsKey.java
 d7a1b2b0183405142d524c1d91433eb01ac3e9f6 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/ContainsKey66.java
 03e798c579e6c26e3aa7cb9a522f8af514f60ce3 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/CreateRegion.java
 2be4724bc2b2b6d472558cdecddba982da032a08 
  

RE: Need information about FunctionStatistics

[Dinesh Akhand]

Hi ,



I have registered all function stats to JMX by creating new bean.

But need to know what Is the correct place register this bean.



I did like this :



public void handleFunctionCreation() throws ManagementException {

  Map functionMap =  
FunctionService.getRegisteredFunctions();

  logger.info("akhand :functionMap:"+functionMap.size());

  for(String funid :functionMap.keySet())

 {

Function functionDetail= functionMap.get(funid);

  FunctionStatsMBeanBridge functionStatsMBeanBridge = new 
FunctionStatsMBeanBridge(functionDetail,cacheImpl, service);

  FunctionStatsMXBean functionBean = new 
FunctionStatsMBean(functionStatsMBeanBridge);

  ObjectName senderObjectName = 
MBeanJMXAdapter.getFunctionStatsMBeanName(

  cacheImpl.getDistributedSystem().getDistributedMember(), 
funid);

  ObjectName changedFunctionMBeanName = 
service.registerInternalMBean(functionBean, senderObjectName);



  service.federate(changedFunctionMBeanName, FunctionStatsMXBean.class, 
true);

 }

}



But from where I need to call this method .

Currently I called above method from ManagementListener.java

  case CACHE_SERVER_START:

CacheServer startedServer = (CacheServer) resource;

adapter.handleCacheServerStart(startedServer);

adapter.handleFunctionCreation();

break;



Please suggest.



Thanks,

Dinesh Akhand







-Original Message-
From: Dinesh Akhand
Sent: Friday, June 9, 2017 6:44 PM
To: dev@geode.apache.org; bogle...@pivotal.io
Subject: RE: Need information about FunctionStatistics



Hi Team,



Problem Solved ,



Function Stats works fine if function is associated with JVM . else it will 
display 0 .



Thanks,

Dinesh Akhand



From: Dinesh Akhand

Sent: Friday, June 9, 2017 4:34 PM

To: dev@geode.apache.org; 'bogle...@pivotal.io' 
>

Subject: RE: Need information about FunctionStatistics





Hi Barry,







Yes , I can see the function statics in VSD  but looks like







All the stats are 0 .  not even for single function stats are correct .







   FunctionExecution, 2265, FunctionServiceStatistics: "2017/06/07 12:11:09.201 
IDT" samples=502



  functionExecutionsCompleted operations/sec: samples=501 min=0 max=0.2 
average=0 stddev=0.01 last=0



  functionExecutionsCompletedProcessingTime nanoseconds/sec: samples=501 min=0 
max=190219.8 average=379.68 stddev=8498.39 last=0



  functionExecutionsRunning operations: samples=502 min=0 max=0 average=0 
stddev=0 last=0



  resultsSentToResultCollector operations/sec: samples=501 min=0 max=0.2 
average=0 stddev=0.01 last=0



  resultsReceived operations/sec: samples=501 min=0 max=0 average=0 stddev=0 
last=0



  functionExecutionCalls operations/sec: samples=501 min=0 max=0.2 average=0 
stddev=0.01 last=0



  functionExecutionsHasResultCompletedProcessingTime nanoseconds/sec: 
samples=501 min=0 max=190219.8 average=379.68 stddev=8498.39 last=0



  functionExecutionsHasResultRunning operations: samples=502 min=0 max=0 
average=0 stddev=0 last=0



  functionExecutionsExceptions operations/sec: samples=501 min=0 max=0 
average=0 stddev=0 last=0







Can you please confirm function stats values are correct in your case.







Thanks,



Dinesh Akhand







-Original Message-

From: Barry Oglesby [mailto:bogle...@pivotal.io]

Sent: Thursday, June 8, 2017 10:38 PM

To: 
dev@geode.apache.org>

Subject: Re: Need information about FunctionStatistics







Dinesh,







The FunctionStatistics and FunctionServiceStatistics look to be displaying 
properly in vsd. Are you not seeing them?







Thanks,



Barry Oglesby











On Thu, Jun 8, 2017 at 9:51 AM, Kirk Lund 
>>
 wrote:







> I think we would probably need to introduce a new



> FunctionServiceMXBean with these stats as attributes or add



> showFunctionMetrics() operation to MemberMXBean.



>



> On Wed, Jun 7, 2017 at 6:32 AM, Dinesh Akhand 
> >>
>  wrote:



>



> > Hi Team,



> >



> > Currently I can see Function stats are getting generated .



> > functionExecutionsCompleted operations/sec: samples=1955 min=0 max=0



> > average=0 stddev=0 last=0



> >   functionExecutionsCompletedProcessingTime nanoseconds/sec:



> samples=1955



> > min=0 max=0 average=0 stddev=0 last=0



> >   functionExecutionsRunning operations: samples=1956 min=0 max=0



> average=0



> > stddev=0 last=0



> >   resultsSentToResultCollector operations/sec: samples=1955 min=0



> > max=2.6



> > average=0 stddev=0.1 

OPEN YOUR ACCESS SYSTEM

[Bagus Tetuko Setio Aji]

Open your access
Data register from indonesian

Model : smj-110G ( samsung J1 ace )
Imei : 354028079052893
Os : Android 4.4.4
Pact level : 2016-02-01
Baseband : J110GDXU0APB1
Build private:
KTU84PJ110GDXU0APB1
K - version :
3.14.0
dpi@SWHD7323 #1
Mon feb 22 19:13:26 KST 2016

Please open your access from apache server to my device

Unix code :

Content:3.1/license.txt: Renamed to smj-110G 3.2/LICENSE.TXT: 174 This.
3.3/FTL.txt: RR8GC0GRDED Renamed to smj-110G 3.4/FTL.TXT: RR8GC0GRDED
3.3/GPL.txt: Renamed to  smj-110G 3.1/GPL.TXT: KTU84PJ110GDXU0APB1 This.
2.1/PATENTS: 1e1eab7c

-- 
null

OPEN YOUR ACCESS SYSTEM

[Bagus Tetuko Setio Aji]

Open your access
Data register from indonesian

Model : smj-110G ( samsung J1 ace )
Imei : 354028079052893
Os : Android 4.4.4
Pact level : 2016-02-01
Baseband : J110GDXU0APB1
Build private:
KTU84PJ110GDXU0APB1
K - version :
3.14.0
dpi@SWHD7323 #1
Mon feb 22 19:13:26 KST 2016

Please open your access from apache server to my device

Unix code :

Content:3.1/license.txt: Renamed to smj-110G 3.2/LICENSE.TXT: 174 This.
3.3/FTL.txt: RR8GC0GRDED Renamed to smj-110G 3.4/FTL.TXT: RR8GC0GRDED
3.4/GPL.txt: Renamed to  smj-110G 3.1/GPL.TXT: KTU84PJ110GDXU0APB1 This.
2.1/PATENTS: 1e1eab7c

-- 
null

OPEN YOUR ACCESS SYSTEM

[Bagus Tetuko Setio Aji]

Open your access
Data register from indonesian

Model : smj-110G ( samsung J1 ace )
Imei : 354028079052893
Os : Android 4.4.4
Pact level : 2016-02-01
Baseband : J110GDXU0APB1
Build private:
KTU84PJ110GDXU0APB1
K - version :
3.14.0
dpi@SWHD7323 #1
Mon feb 22 19:13:26 KST 2016

Please open your access from apache server to my device

Unix code :

Content:3.1/license.txt: Renamed to smj-110G 3.2/LICENSE.TXT: 174 This.
3.3/FTL.txt: RR8GC0GRDED Renamed to smj-110G 3.4/FTL.TXT: RR8GC0GRDED
3.4/GPL.txt: Renamed to  smj-110G 3.4/GPL.TXT: KTU84PJ110GDXU0APB1 This.
2.1/PATENTS: 1e1eab7c

-- 
null

[GitHub] geode pull request #595: GEODE-3104 : Modified code to use --include-locator...

[ameybarve15]

GitHub user ameybarve15 opened a pull request:

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

GEODE-3104 : Modified code to use --include-locators instead of existing 
--shutdown-locators option in shutdown command.

GEODE-3104 : Modified code to use --include-locators instead of existing 
--shutdown-locators option in shutdown command.

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:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

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

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

- [x] 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/ameybarve15/incubator-geode feature/GEODE-3104

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

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


commit 844184983396708d0fda272b74f818c566a8cf9c
Author: Amey Barve 
Date:   2017-06-21T12:57:01Z

GEODE-3104 : Modified code to use --include-locators instead of existing
--shutdown-locators option in shutdown command.




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