date:20170505


[ 
https://issues.apache.org/jira/browse/GEODE-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999173#comment-15999173
 ] 

ASF GitHub Bot commented on GEODE-2870:
---

Github user jhuynh1 closed the pull request at:

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


> BucketMovedException during function execution may lead to client missing 
> results
> -
>
> Key: GEODE-2870
> URL: https://issues.apache.org/jira/browse/GEODE-2870
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Affects Versions: 1.1.0
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> If a function isHA and hasResult, if checkForBucketMovement() throws the 
> BucketMovedException, this escapes the synchronized lastResult() method.  
> Propogating this to through the user function.  
> Hopefully the user function does something appropriate or allows it to 
> propagate to AbstractExecution.executeFunctionLocally(), which hands it to 
> handleException.  Here is where the exception is written back to the client.
> However, because we have now escaped the synchronized method, the thread can 
> be paused.  
> A remote execution returns with results and now enters the synchronized 
> lastResult() method.  The state flags have been set and now this result is 
> considered the last result and lastResult is now sent.  We end up not 
> retrying even though the local node had failed.  It just hadn't had the 
> opportunity to send the exception back.
> This issue has probably been in the product for a long time.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #491: GEODE-2870: Local node function execution failure c...

2017-05-05 Thread jhuynh1

Github user jhuynh1 closed the pull request at:

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


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

[jira] [Created] (GEODE-2890) Incorrect debug log location in AbstractGatewaySenderEventProcessor.processQueue()

2017-05-05 Thread Jason Huynh (JIRA)

Jason Huynh created GEODE-2890:
--

 Summary: Incorrect debug log location in 
AbstractGatewaySenderEventProcessor.processQueue() 
 Key: GEODE-2890
 URL: https://issues.apache.org/jira/browse/GEODE-2890
 Project: Geode
  Issue Type: Bug
  Components: wan
Reporter: Jason Huynh


The following code snippet in processQueue() for AEQ's appears to be outside of 
an if condition where we check to see if the node is primary still or not.  
This line prints for every event and I believe it should be inside the previous 
if condition. 

{noformat}
if (qpr != null) {
   BucketRegion bucket = qpr.getDataStore().getLocalBucketById(bucketId);
   if (bucket == null || !bucket.getBucketAdvisor().isPrimary()) {
 event.setPossibleDuplicate(true);
//I think the debug log should be placed here?
   }
}
if (isDebugEnabled) {
  logger.debug( "Bucket id: {} is no longer primary on this node. The event {} 
will be dispatched from this node with possibleDuplicate set to true.", 
bucketId, event);
}
{noformat}





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2889) Generic session module should touch sessions rather than recreate the native session


[ 
https://issues.apache.org/jira/browse/GEODE-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999168#comment-15999168
 ] 

ASF GitHub Bot commented on GEODE-2889:
---

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/494
  
@jhuynh1 @jdeppe-pivotal 


> Generic session module should touch sessions rather than recreate the native 
> session
> 
>
> Key: GEODE-2889
> URL: https://issues.apache.org/jira/browse/GEODE-2889
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Dan Smith
>
> The session module for generic application servers is doing some magic to try 
> to recreate native sessions if they have been idle for too long. This can 
> cause failures if the container expires a session concurrently, because the 
> expiration can happen after we have checked if the session is valid, but 
> before we can read the session creation time.
> {noformat}
> /*
>  * This is a massively gross hack. Currently, there is no way to 
> actually update the last
>  * accessed time for a session, so what we do here is once we're into 
> X% of the session's
>  * TTL we grab a new session from the container.
>  *
>  * (inactive * 1000) * (pct / 100) ==> (inactive * 10 * pct)
>  */
> if (session.getLastAccessedTime()
> - session.getCreationTime() > (session.getMaxInactiveInterval() * 
> 10
> * percentInactiveTimeTriggerRebuild)) {
>   HttpSession nativeSession = super.getSession();
>   session.failoverSession(nativeSession);
> }
> {noformat}
> Instead of this, we should just call getSession on the container and have it 
> update the last accessed time of the native session.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #494: GEODE-2889: Update the last access time of native sessions

2017-05-05 Thread upthewaterspout

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/494
  
@jhuynh1 @jdeppe-pivotal 


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

[jira] [Commented] (GEODE-2889) Generic session module should touch sessions rather than recreate the native session


[ 
https://issues.apache.org/jira/browse/GEODE-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999167#comment-15999167
 ] 

ASF GitHub Bot commented on GEODE-2889:
---

GitHub user upthewaterspout opened a pull request:

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

GEODE-2889: Update the last access time of native sessions

Our getSession method had some races where we were holding onto a
reference to the native session, but not updating the last accessed time
of the native session by calling into getSession of the container. This
could allow the container to expire the session in the middle of our
method.

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

$ git pull https://github.com/upthewaterspout/incubator-geode 
feature/GEODE-2889

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

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


commit a9a79d54c782e13763f0c4a1b3bef4293804fb7e
Author: Dan Smith 
Date:   2017-05-03T22:49:57Z

GEODE-2889: Update the last access time of native sessions

Our getSession method had some races where we were holding onto a
reference to the native session, but not updating the last accessed time
of the native session by calling into getSession of the container. This
could allow the container to expire the session in the middle of our
method.




> Generic session module should touch sessions rather than recreate the native 
> session
> 
>
> Key: GEODE-2889
> URL: https://issues.apache.org/jira/browse/GEODE-2889
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Dan Smith
>
> The session module for generic application servers is doing some magic to try 
> to recreate native sessions if they have been idle for too long. This can 
> cause failures if the container expires a session concurrently, because the 
> expiration can happen after we have checked if the session is valid, but 
> before we can read the session creation time.
> {noformat}
> /*
>  * This is a massively gross hack. Currently, there is no way to 
> actually update the last
>  * accessed time for a session, so what we do here is once we're into 
> X% of the session's
>  * TTL we grab a new session from the container.
>  *
>  * (inactive * 1000) * (pct / 100) ==> (inactive * 10 * pct)
>  */
> if (session.getLastAccessedTime()
> - session.getCreationTime() > (session.getMaxInactiveInterval() * 
> 10
> * percentInactiveTimeTriggerRebuild)) {
>   HttpSession nativeSession = super.getSession();
>   session.failoverSession(nativeSession);
> }
> {noformat}
> Instead of this, we should just call getSession on the container and have it 
> update the last accessed time of the native session.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #494: GEODE-2889: Update the last access time of native s...

2017-05-05 Thread upthewaterspout

GitHub user upthewaterspout opened a pull request:

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

GEODE-2889: Update the last access time of native sessions

Our getSession method had some races where we were holding onto a
reference to the native session, but not updating the last accessed time
of the native session by calling into getSession of the container. This
could allow the container to expire the session in the middle of our
method.

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

$ git pull https://github.com/upthewaterspout/incubator-geode 
feature/GEODE-2889

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

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


commit a9a79d54c782e13763f0c4a1b3bef4293804fb7e
Author: Dan Smith 
Date:   2017-05-03T22:49:57Z

GEODE-2889: Update the last access time of native sessions

Our getSession method had some races where we were holding onto a
reference to the native session, but not updating the last accessed time
of the native session by calling into getSession of the container. This
could allow the container to expire the session in the middle of our
method.




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

[jira] [Created] (GEODE-2889) Generic session module should touch sessions rather than recreate the native session

2017-05-05 Thread Dan Smith (JIRA)

Dan Smith created GEODE-2889:


 Summary: Generic session module should touch sessions rather than 
recreate the native session
 Key: GEODE-2889
 URL: https://issues.apache.org/jira/browse/GEODE-2889
 Project: Geode
  Issue Type: Bug
  Components: http session
Reporter: Dan Smith


The session module for generic application servers is doing some magic to try 
to recreate native sessions if they have been idle for too long. This can cause 
failures if the container expires a session concurrently, because the 
expiration can happen after we have checked if the session is valid, but before 
we can read the session creation time.

{noformat}
/*
 * This is a massively gross hack. Currently, there is no way to 
actually update the last
 * accessed time for a session, so what we do here is once we're into 
X% of the session's
 * TTL we grab a new session from the container.
 *
 * (inactive * 1000) * (pct / 100) ==> (inactive * 10 * pct)
 */
if (session.getLastAccessedTime()
- session.getCreationTime() > (session.getMaxInactiveInterval() * 10
* percentInactiveTimeTriggerRebuild)) {
  HttpSession nativeSession = super.getSession();
  session.failoverSession(nativeSession);
}
{noformat}

Instead of this, we should just call getSession on the container and have it 
update the last accessed time of the native session.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2613) Incorrect security privilege listed for 'execute function'


 [ 
https://issues.apache.org/jira/browse/GEODE-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Barnes resolved GEODE-2613.

Resolution: Duplicate

Same as GEODE-2830

> Incorrect security privilege listed for 'execute function'
> --
>
> Key: GEODE-2613
> URL: https://issues.apache.org/jira/browse/GEODE-2613
> Project: Geode
>  Issue Type: Bug
>  Components: docs, security
>Reporter: Diane Hardman
>Assignee: Dave Barnes
>
> Under 'Implementing Authorization" are 2 tables; one for client operations 
> and another for general gfsh commands. 'execute function' is listed in both 
> tables but with different privilege requirements.
> The correct privilege required is DATA:WRITE for 'execute function' in either 
> context.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2613) Incorrect security privilege listed for 'execute function'


 [ 
https://issues.apache.org/jira/browse/GEODE-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Barnes reassigned GEODE-2613:
--

Assignee: Dave Barnes

> Incorrect security privilege listed for 'execute function'
> --
>
> Key: GEODE-2613
> URL: https://issues.apache.org/jira/browse/GEODE-2613
> Project: Geode
>  Issue Type: Bug
>  Components: docs, security
>Reporter: Diane Hardman
>Assignee: Dave Barnes
>
> Under 'Implementing Authorization" are 2 tables; one for client operations 
> and another for general gfsh commands. 'execute function' is listed in both 
> tables but with different privilege requirements.
> The correct privilege required is DATA:WRITE for 'execute function' in either 
> context.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2815) Incorrect Error Message in REST API docs for {region}/{key} HTTP.GET command


[ 
https://issues.apache.org/jira/browse/GEODE-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999119#comment-15999119
 ] 

ASF GitHub Bot commented on GEODE-2815:
---

GitHub user davebarnes97 opened a pull request:

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

GEODE-2815 Incorrect Error Message in REST API docs for {region}/{key…

…} HTTP.GET command

404 does mean 'not found', and in the REST API context it can mean 'Region 
not found', 'Key not found' or 'Either key or region not found', depending on 
what was being requested.
Edited the various REST API command docs accordingly.



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

$ git pull https://github.com/davebarnes97/geode feature/GEODE-2815

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

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


commit d2b99aeb5e28307c95963c8ee4a2ce5bf979f7a9
Author: Dave Barnes 
Date:   2017-05-05T21:37:07Z

GEODE-2815 Incorrect Error Message in REST API docs for {region}/{key} 
HTTP.GET command




> Incorrect Error Message in REST API docs for {region}/{key} HTTP.GET command
> 
>
> Key: GEODE-2815
> URL: https://issues.apache.org/jira/browse/GEODE-2815
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Affects Versions: 1.1.1, 1.2.0
>Reporter: Michael Martell
>Assignee: Dave Barnes
>Priority: Minor
>
> According to the docs at 
> http://gemfire.docs.pivotal.io/geode/rest_apps/get_region_key_data.html error 
> responses HTTP 400 and HTTP 404 appear to be very similar,
> # 400 - BAD REQUEST - Returned if the supplied key is not found in the region.
> # 404 - NOT FOUND - Returned if key does not exist for the region.
> The source code at PdxBasedCrudController.java:210 & 213 show that 404 
> actually means "Region does not exist", thus the documentation appears to be 
> incorrect. Other commands are correct in the docs showing 404 means region 
> does not exist.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #493: GEODE-2815 Incorrect Error Message in REST API docs...

2017-05-05 Thread davebarnes97

GitHub user davebarnes97 opened a pull request:

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

GEODE-2815 Incorrect Error Message in REST API docs for {region}/{keyâ¦

â¦} HTTP.GET command

404 does mean 'not found', and in the REST API context it can mean 'Region 
not found', 'Key not found' or 'Either key or region not found', depending on 
what was being requested.
Edited the various REST API command docs accordingly.



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

$ git pull https://github.com/davebarnes97/geode feature/GEODE-2815

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

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


commit d2b99aeb5e28307c95963c8ee4a2ce5bf979f7a9
Author: Dave Barnes 
Date:   2017-05-05T21:37:07Z

GEODE-2815 Incorrect Error Message in REST API docs for {region}/{key} 
HTTP.GET 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.
---

[jira] [Created] (GEODE-2888) user guide: REST API Region Endpoints use 'gemfire-api' in their names

Dave Barnes created GEODE-2888:
--

 Summary: user guide: REST API Region Endpoints use  'gemfire-api' 
in their names
 Key: GEODE-2888
 URL: https://issues.apache.org/jira/browse/GEODE-2888
 Project: Geode
  Issue Type: Improvement
  Components: docs
Reporter: Dave Barnes


The name 'gemfire-api' should be replaced by 'geode' in the Region Endpoints 
section of the manual. See 
http://geode.apache.org/docs/guide/11/rest_apps/rest_regions.html and its 
subsections.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #97: Ignore me. This is a test for Scott

2017-05-05 Thread dgkimura

GitHub user dgkimura opened a pull request:

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

Ignore me. This is a test for Scott

Ignore me. This is a test for Scott

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

$ git pull https://github.com/dgkimura/geode-native 
wip/test-windows-separator

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

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


commit 1f0d181b30fc711edba3c0d79394b037c06dc35a
Author: David Kimura 
Date:   2017-04-12T17:18:21Z

GEODE-2740: Add region factory member reference to cache

commit 9a74e49560c50db9f3e6c802140b39838216e540
Author: David Kimura 
Date:   2017-04-12T18:16:34Z

GEODE-2740: CacheFactory keeps a reference to cache it created

commit 18e1615aec0441f3b9a2a855bd6339a8596f11ff
Author: David Kimura 
Date:   2017-04-12T20:21:42Z

GEODE-2740: Cache factory create gets from cache map

commit 50a36f529e192f8499d57fa4f5ac587541982e24
Author: David Kimura 
Date:   2017-04-13T20:39:32Z

GEODE-2740: Update cache factory methods to non-static and add s_factory

commit fc04a489d1a8c8c3085bf5c329322ccc326fb953
Author: David Kimura 
Date:   2017-04-13T21:38:52Z

GEODE-2740: Store cache factory cachemap in object instance

commit f195047affc0e530316d3e63dd71f953ea81364b
Author: David Kimura 
Date:   2017-04-13T21:43:59Z

GEODE-2740: Remove cache factory's unused method handle xml

commit 79684a6a0e2a33b7b60e0c6286ffc4ff3f88a9ce
Author: David Kimura 
Date:   2017-04-14T16:33:53Z

GEODE-2740: Convert global cache factory lock to per-instance level lock

commit 89258a7eb05ed0f4ce690fe79ec4ebcf1801fce8
Author: David Kimura 
Date:   2017-04-14T19:59:51Z

GEODE-2740: Remove global cache factory variables

commit 9e739e65c9b4981fdd88d7e680dc07d4508fd557
Author: Mark Hanson 
Date:   2017-04-19T00:33:00Z

latest changes for pulling out shared ptr

commit 2efad862db985823e39e66f67efeb99eab95e483
Author: Mark Hanson 
Date:   2017-04-19T18:16:31Z

Updates for removing globals.

commit c5192a329ee9a31f75422ebca4d744f8c419ec0c
Author: Mark Hanson 
Date:   2017-04-19T23:29:23Z

"Destaticifying" the code, this checkin will not compile, but we are
preserving our work...

commit 46b7706c1c51f8a716daa6891ceeb620901a8ad9
Author: Mark Hanson 
Date:   2017-04-21T00:12:18Z

fixing pool manager references to use a singleton rather than static methods

commit ff86e9e38486f7a7d8ef2417eac480f2f1c5bf37
Author: David Kimura 
Date:   2017-05-05T23:20:30Z

Test windows separator




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

[jira] [Commented] (GEODE-2815) Incorrect Error Message in REST API docs for {region}/{key} HTTP.GET command


[ 
https://issues.apache.org/jira/browse/GEODE-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999101#comment-15999101
 ] 

Dave Barnes commented on GEODE-2815:


Digging a bit deeper, 404 does mean 'not found', and in the REST API context it 
can mean  'Region not found', 'Key not found' or 'Either key or region not 
found', depending on what was being requested.
Edited the various REST API command docs accordingly.

> Incorrect Error Message in REST API docs for {region}/{key} HTTP.GET command
> 
>
> Key: GEODE-2815
> URL: https://issues.apache.org/jira/browse/GEODE-2815
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Affects Versions: 1.1.1, 1.2.0
>Reporter: Michael Martell
>Assignee: Dave Barnes
>Priority: Minor
>
> According to the docs at 
> http://gemfire.docs.pivotal.io/geode/rest_apps/get_region_key_data.html error 
> responses HTTP 400 and HTTP 404 appear to be very similar,
> # 400 - BAD REQUEST - Returned if the supplied key is not found in the region.
> # 404 - NOT FOUND - Returned if key does not exist for the region.
> The source code at PdxBasedCrudController.java:210 & 213 show that 404 
> actually means "Region does not exist", thus the documentation appears to be 
> incorrect. Other commands are correct in the docs showing 404 means region 
> does not exist.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 59035: GEODE-2883: Fix GFSH gc heap size output


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

(Updated May 5, 2017, 11:19 p.m.)


Review request for geode, Barry Oglesby, Jinmei Liao, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Changes
---

Remove unused import.


Repository: geode


Description
---

GEODE-2883: Fix GFSH gc heap size output


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/GarbageCollectionFunction.java
 354d353 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/BytesToString.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/BytesToStringTest.java
 PRE-CREATION 


Diff: https://reviews.apache.org/r/59035/diff/3/

Changes: https://reviews.apache.org/r/59035/diff/2-3/


Testing
---

Precheckin started (still running)


Thanks,

Jared Stewart

Re: Review Request 59035: GEODE-2883: Fix GFSH gc heap size output

2017-05-05 Thread ASF subversion and git services (JIRA)


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




geode-core/src/test/java/org/apache/geode/management/internal/cli/util/BytesToStringTest.java
Line 27 (original), 19 (patched)


Unused import?


- Ken Howe


On May 5, 2017, 11:08 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59035/
> ---
> 
> (Updated May 5, 2017, 11:08 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, Jinmei Liao, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2883: Fix GFSH gc heap size output
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/GarbageCollectionFunction.java
>  354d353 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/BytesToString.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/BytesToStringTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/59035/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin started (still running)
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[jira] [Commented] (GEODE-2879) LonerDistributionManager's Shutdown not being called in close()


[ 
https://issues.apache.org/jira/browse/GEODE-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999099#comment-15999099
 ] 

ASF subversion and git services commented on GEODE-2879:


Commit 288676dfed0d6d4e0b20e81b2392854fa1204cb6 in geode's branch 
refs/heads/develop from [~nnag]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=288676d ]

Revert "GEODE-2879: LonerDistributionManager shutdown called from close"

This reverts commit 149e06d53a33fa7363da15bf3f9cb248d94fabf5.


> LonerDistributionManager's Shutdown not being called in close()
> ---
>
> Key: GEODE-2879
> URL: https://issues.apache.org/jira/browse/GEODE-2879
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> Issue:
> LonerDistributionManager shutdown was not being called from close() method 
> call.
> This resulted in the thread pool's threads to wait for 1 minute of inactivity 
> for them to be killed.
> This resulted in an extra delay while test executions.
> Solution:
> Call shutdown from close()



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 59035: GEODE-2883: Fix GFSH gc heap size output


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


Fix it, then Ship it!





geode-core/src/test/java/org/apache/geode/management/internal/cli/util/BytesToStringTest.java
Lines 1 (patched)


package should come after the license comment



geode-core/src/test/java/org/apache/geode/management/internal/cli/util/BytesToStringTest.java
Lines 122-123 (patched)


Test doesn't belong in this class


- Ken Howe


On May 5, 2017, 11:08 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59035/
> ---
> 
> (Updated May 5, 2017, 11:08 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, Jinmei Liao, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2883: Fix GFSH gc heap size output
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/GarbageCollectionFunction.java
>  354d353 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/BytesToString.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/BytesToStringTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/59035/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin started (still running)
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 58996: GEODE-2876: Add logging to diagnose CI failure


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

(Updated May 5, 2017, 11:15 p.m.)


Review request for geode.


Repository: geode


Description
---

GEODE-2876: Add logging to diagnose CI failure


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
 20ae022 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
 c2c6e14 


Diff: https://reviews.apache.org/r/58996/diff/2/

Changes: https://reviews.apache.org/r/58996/diff/1-2/


Testing
---


Thanks,

Jared Stewart

Re: Review Request 59035: GEODE-2883: Fix GFSH gc heap size output


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

(Updated May 5, 2017, 11:08 p.m.)


Review request for geode, Barry Oglesby, Jinmei Liao, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Changes
---

Removed some extraneous code


Repository: geode


Description
---

GEODE-2883: Fix GFSH gc heap size output


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/GarbageCollectionFunction.java
 354d353 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/BytesToString.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/BytesToStringTest.java
 PRE-CREATION 


Diff: https://reviews.apache.org/r/59035/diff/2/

Changes: https://reviews.apache.org/r/59035/diff/1-2/


Testing
---

Precheckin started (still running)


Thanks,

Jared Stewart

Review Request 59035: GEODE-2883: Fix GFSH gc heap size output

2017-05-05 Thread ASF subversion and git services (JIRA)


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

Review request for geode, Barry Oglesby, Jinmei Liao, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-2883: Fix GFSH gc heap size output


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/GarbageCollectionFunction.java
 354d3530e0cd07696754a2abc8e87d91f8846bb6 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/BytesToString.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/BytesToStringTest.java
 PRE-CREATION 


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


Testing
---

Precheckin started (still running)


Thanks,

Jared Stewart

Re: Review Request 59034: GEODE-2352 Document that REST API requires two properties

2017-05-05 Thread Joey McAllister


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


Ship it!




Ship It!

- Joey McAllister


On May 5, 2017, 10:32 p.m., Dave Barnes wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59034/
> ---
> 
> (Updated May 5, 2017, 10:32 p.m.)
> 
> 
> Review request for geode, Hitesh Khamesra, Joey McAllister, and Pulkit 
> Chandra.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2352 Document that REST API requires two properties
> 
> 
> Diffs
> -
> 
>   geode-docs/rest_apps/chapter_overview.html.md.erb 
> 5e48675b7eba37ae3f6cd078111c0acf09d9ae68 
>   geode-docs/rest_apps/rest_prereqs.html.md.erb 
> 935f94b2caf83478bd0ac97dc797ccdcee695b8c 
>   geode-docs/rest_apps/setup_config.html.md.erb 
> 71c50f53dbc080f9d973b268eade9cb03c05e746 
> 
> 
> Diff: https://reviews.apache.org/r/59034/diff/1/
> 
> 
> Testing
> ---
> 
> The two properties, `http-service-bind-address` and `http-service-port`, are 
> not *mandatory* as stated in the ticket, but if allowed to default, they may 
> not be publicly visible. So we'll say they're optional, but that it's *good 
> practice* to specify them for visibility.
> This checkin also picks up some other corrections regarding API library name 
> and some format fixes.
> 
> 
> Thanks,
> 
> Dave Barnes
> 
>

[jira] [Commented] (GEODE-2887) Exclude build-* output directories from rat license checking


[ 
https://issues.apache.org/jira/browse/GEODE-2887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999077#comment-15999077
 ] 

ASF subversion and git services commented on GEODE-2887:


Commit 3674f70a74b7eeb23d5e2f2cc8f6d9cf42182650 in geode's branch 
refs/heads/feature/GEODE-2858 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3674f70 ]

GEODE-2887: exclude build-* output directories from rat


> Exclude build-* output directories from rat license checking
> 
>
> Key: GEODE-2887
> URL: https://issues.apache.org/jira/browse/GEODE-2887
> Project: Geode
>  Issue Type: Wish
>  Components: build
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The rat.gradle excludes "build" which is the directory that gradle writes to 
> when building geode on the command-line.
> I'd like to configure IntelliJ to write output to build-intellij and have 
> this not cause rat failures when building my checkout on the command-line.
> I've also seen others configure Eclipse to write output to build-eclipse, so 
> "build-*" would be a good pattern to add to the rat exclusions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2887) Exclude build-* output directories from rat license checking


 [ 
https://issues.apache.org/jira/browse/GEODE-2887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund reassigned GEODE-2887:


Assignee: Kirk Lund

> Exclude build-* output directories from rat license checking
> 
>
> Key: GEODE-2887
> URL: https://issues.apache.org/jira/browse/GEODE-2887
> Project: Geode
>  Issue Type: Wish
>  Components: build
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The rat.gradle excludes "build" which is the directory that gradle writes to 
> when building geode on the command-line.
> I'd like to configure IntelliJ to write output to build-intellij and have 
> this not cause rat failures when building my checkout on the command-line.
> I've also seen others configure Eclipse to write output to build-eclipse, so 
> "build-*" would be a good pattern to add to the rat exclusions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-05-05 Thread Spring CI


---
Spring Data GemFire > Nightly-ApacheGeode > #545 was successful.
---
Scheduled
1845 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[jira] [Assigned] (GEODE-2883) gfsh gc reports incorrect heap sizes

2017-05-05 Thread Jared Stewart (JIRA)


 [ 
https://issues.apache.org/jira/browse/GEODE-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jared Stewart reassigned GEODE-2883:


Assignee: Jared Stewart

> gfsh gc reports incorrect heap sizes
> 
>
> Key: GEODE-2883
> URL: https://issues.apache.org/jira/browse/GEODE-2883
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Jared Stewart
>
> I have 3 servers each with -Xms1g and -Xmx1g, and I load some data.
> If I run a gfsh gc, it reports:
> {noformat}
> GC Summary
>   Member ID/Name| HeapSize (MB) Before GC | HeapSize(MB) After GC 
> | Time Taken for GC in ms
> --- | --- | - 
> | ---
> 192.168.2.7(98588):1025 | 2078| 1098  
> | 516
> 192.168.2.7(98602):1027 | 1942| 1110  
> | 530
> 192.168.2.7(98595):1026 | 2019| 1109  
> | 531
> {noformat}
> The heap sizes before and after are higher than they should be.
> I added some debugging in the GarbageCollectionFunction, and it shows:
> {noformat}
> GarbageCollectionFunction.execute freeMemoryBeforeGC=765581248; 
> totalMemoryBeforeGC=1037959168
> GarbageCollectionFunction.execute freeMemoryAfterGC=893946464; 
> totalMemoryAfterGC=1037959168
> GarbageCollectionFunction.execute HeapSizeBeforeGC=2078
> GarbageCollectionFunction.execute HeapSizeAfterGC=1098
> GarbageCollectionFunction.execute freeMemoryBeforeGC=773307528; 
> totalMemoryBeforeGC=1037959168
> GarbageCollectionFunction.execute freeMemoryAfterGC=892508088; 
> totalMemoryAfterGC=1037959168
> GarbageCollectionFunction.execute HeapSizeBeforeGC=2019
> GarbageCollectionFunction.execute HeapSizeAfterGC=1109
> GarbageCollectionFunction.execute freeMemoryBeforeGC=783373464; 
> totalMemoryBeforeGC=1037959168
> GarbageCollectionFunction.execute freeMemoryAfterGC=892349664; 
> totalMemoryAfterGC=1037959168
> GarbageCollectionFunction.execute HeapSizeBeforeGC=1942
> GarbageCollectionFunction.execute HeapSizeAfterGC=1110
> {noformat}
> The free and total memory are fine, but the heap sizes before and after are 
> incorrect.
> The function is using 131072 as its divisor
> {noformat}
> 1037959168-765581248=272377920 / 131072 = 2078
> 1037959168-893946464=144012704 / 131072 = 1098
> {noformat}
> It should be using 1024*1024.
> {noformat}
> 1037959168-765581248=272377920 / (1024*1024) = 259
> 1037959168-893946464=144012704 / (1024*1024) = 137
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2887) Exclude build-* output directories from rat license checking


 [ 
https://issues.apache.org/jira/browse/GEODE-2887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-2887:
-
Description: 
The rat.gradle excludes "build" which is the directory that gradle writes to 
when building geode on the command-line.

I'd like to configure IntelliJ to write output to build-intellij and have this 
not cause rat failures when building my checkout on the command-line.

I've also seen others configure Eclipse to write output to build-eclipse, so 
"build-*" would be a good pattern to add to the rat exclusions.


  was:
The rat.gradle excludes \**/build/\** which is the directory that gradle writes 
to when building geode on the command-line.

I'd like to configure IntelliJ to write output to build-intellij and have this 
not cause rat failures when building my checkout on the command-line.

I've also seen others configure Eclipse to write output to build-eclipse, so 
**/build-*/** would be a good pattern to exclude in addition to **/build/**.



> Exclude build-* output directories from rat license checking
> 
>
> Key: GEODE-2887
> URL: https://issues.apache.org/jira/browse/GEODE-2887
> Project: Geode
>  Issue Type: Wish
>  Components: build
>Reporter: Kirk Lund
>
> The rat.gradle excludes "build" which is the directory that gradle writes to 
> when building geode on the command-line.
> I'd like to configure IntelliJ to write output to build-intellij and have 
> this not cause rat failures when building my checkout on the command-line.
> I've also seen others configure Eclipse to write output to build-eclipse, so 
> "build-*" would be a good pattern to add to the rat exclusions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2887) Exclude build-* output directories from rat license checking


 [ 
https://issues.apache.org/jira/browse/GEODE-2887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-2887:
-
Description: 
The rat.gradle excludes \**/build/\** which is the directory that gradle writes 
to when building geode on the command-line.

I'd like to configure IntelliJ to write output to build-intellij and have this 
not cause rat failures when building my checkout on the command-line.

I've also seen others configure Eclipse to write output to build-eclipse, so 
**/build-*/** would be a good pattern to exclude in addition to **/build/**.


  was:
The rat.gradle excludes {code}**/build/**{code} which is the directory that 
gradle writes to when building geode on the command-line.

I'd like to configure IntelliJ to write output to build-intellij and have this 
not cause rat failures when building my checkout on the command-line.

I've also seen others configure Eclipse to write output to build-eclipse, so 
**/build-*/** would be a good pattern to exclude in addition to **/build/**.



> Exclude build-* output directories from rat license checking
> 
>
> Key: GEODE-2887
> URL: https://issues.apache.org/jira/browse/GEODE-2887
> Project: Geode
>  Issue Type: Wish
>  Components: build
>Reporter: Kirk Lund
>
> The rat.gradle excludes \**/build/\** which is the directory that gradle 
> writes to when building geode on the command-line.
> I'd like to configure IntelliJ to write output to build-intellij and have 
> this not cause rat failures when building my checkout on the command-line.
> I've also seen others configure Eclipse to write output to build-eclipse, so 
> **/build-*/** would be a good pattern to exclude in addition to **/build/**.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 58682: GEODE-2662: Missing keys cause columns to shift in gfsh table display.



> On May 5, 2017, 10:03 p.m., Ken Howe wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
> > Line 91 (original)
> > 
> >
> > We should be using log4j levels, so restore this line. All of the 
> > "fineEnabled" and "logger.fine" should be "logger.isTraceEnabled" and 
> > "logger.trace"
> > 
> > Then remove all the local declarations of:
> > 
> >LogWriter logger = cache.getLogger();
> 
> Kirk Lund wrote:
> "fine" translates to isDebugEnabled and logger.debug
> 
> "finer" and "finest" both translate to isTraceEnabled and logger.trace

I stand corrected! I should have looked up the level translations instead of 
making a comment from memory.


- Ken


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


On May 5, 2017, 9:22 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58682/
> ---
> 
> (Updated May 5, 2017, 9:22 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added unittests to capture failing behavior.
> 
> Corrected buildTable shifting columns when adding values with additional keys.
> 
> 
> Refactoring of DataCommandResult and DataCommandFunction
> 
> --
> 
> The majority of changes to DataCommandFunction and DataCommandResult are 
> refactoring.  Two ignored exceptions have been explicitly noted in the logger.
> 
> - In DataCommandFunction:423, there's an empty if block.  I imagine I should 
> remove that, since empty code is a waste.  Looking for it, I couldn't find 
> the comment-hinted separate method, though. Anyone familiar with this corner 
> of the code know if that actuall happens?
> 
> - Qualitative changes are in DataCommandResult.buildTable.  Items in the 
> table are scanned to build an agggregate key set, and those items missing any 
> of these keys are padded with `MISSING_VALUE`.
> 
> - I moved some of the more cumbersome blocks of code to subfunctions, but may 
> have done this more than necessary.  Opinions?
> 
> - Introduced DataCommandFunctionWithPDXJUnitTest to explicitly drive 
> development / note the bug in GEODE-2662.  Are there additional tests that 
> would fit naturally in this file?
> 
> 
> Diffs
> -
> 
>   geode-core/build.gradle f07444a 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
>  29d68bd 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/DataCommandResult.java
>  423d781 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DataCommandFunction.java
>  bb77466 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/TabularResultData.java
>  e72654e 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryDataInconsistencyDUnitTest.java
>  1af6261 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/GemfireDataCommandsDUnitTest.java
>  0e2a41e 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DataCommandFunctionWithPDXJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  ead1047 
> 
> 
> Diff: https://reviews.apache.org/r/58682/diff/7/
> 
> 
> Testing
> ---
> 
> Previous precheckin returned fully green.  Running with new refactoring but 
> expect no issues.  (Common last words.)
> 
> 
> Thanks,
> 
> Patrick Rhomberg
> 
>

[jira] [Created] (GEODE-2887) Exclude build-* output directories from rat license checking

Kirk Lund created GEODE-2887:


 Summary: Exclude build-* output directories from rat license 
checking
 Key: GEODE-2887
 URL: https://issues.apache.org/jira/browse/GEODE-2887
 Project: Geode
  Issue Type: Wish
  Components: build
Reporter: Kirk Lund


The rat.gradle excludes **/build/** which is the directory that gradle writes 
to when building geode on the command-line.

I'd like to configure IntelliJ to write output to build-intellij and have this 
not cause rat failures when building my checkout on the command-line.

I've also seen others configure Eclipse to write output to build-eclipse, so 
**/build-*/** would be a good pattern to exclude in addition to **/build/**.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 58682: GEODE-2662: Missing keys cause columns to shift in gfsh table display.

2017-05-05 Thread Kirk Lund



> On May 5, 2017, 10:03 p.m., Ken Howe wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
> > Line 91 (original)
> > 
> >
> > We should be using log4j levels, so restore this line. All of the 
> > "fineEnabled" and "logger.fine" should be "logger.isTraceEnabled" and 
> > "logger.trace"
> > 
> > Then remove all the local declarations of:
> > 
> >LogWriter logger = cache.getLogger();

"fine" translates to isDebugEnabled and logger.debug

"finer" and "finest" both translate to isTraceEnabled and logger.trace


- Kirk


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


On May 5, 2017, 9:22 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58682/
> ---
> 
> (Updated May 5, 2017, 9:22 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added unittests to capture failing behavior.
> 
> Corrected buildTable shifting columns when adding values with additional keys.
> 
> 
> Refactoring of DataCommandResult and DataCommandFunction
> 
> --
> 
> The majority of changes to DataCommandFunction and DataCommandResult are 
> refactoring.  Two ignored exceptions have been explicitly noted in the logger.
> 
> - In DataCommandFunction:423, there's an empty if block.  I imagine I should 
> remove that, since empty code is a waste.  Looking for it, I couldn't find 
> the comment-hinted separate method, though. Anyone familiar with this corner 
> of the code know if that actuall happens?
> 
> - Qualitative changes are in DataCommandResult.buildTable.  Items in the 
> table are scanned to build an agggregate key set, and those items missing any 
> of these keys are padded with `MISSING_VALUE`.
> 
> - I moved some of the more cumbersome blocks of code to subfunctions, but may 
> have done this more than necessary.  Opinions?
> 
> - Introduced DataCommandFunctionWithPDXJUnitTest to explicitly drive 
> development / note the bug in GEODE-2662.  Are there additional tests that 
> would fit naturally in this file?
> 
> 
> Diffs
> -
> 
>   geode-core/build.gradle f07444a 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
>  29d68bd 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/DataCommandResult.java
>  423d781 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DataCommandFunction.java
>  bb77466 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/TabularResultData.java
>  e72654e 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryDataInconsistencyDUnitTest.java
>  1af6261 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/GemfireDataCommandsDUnitTest.java
>  0e2a41e 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DataCommandFunctionWithPDXJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  ead1047 
> 
> 
> Diff: https://reviews.apache.org/r/58682/diff/7/
> 
> 
> Testing
> ---
> 
> Previous precheckin returned fully green.  Running with new refactoring but 
> expect no issues.  (Common last words.)
> 
> 
> Thanks,
> 
> Patrick Rhomberg
> 
>

Re: Development Help!

Aashita, you probably want the u...@geode.apache.org group.  The 
dev@geode.apache.org group is for people to discuss development of 
Geode, not problems with using it.


Le 5/5/2017 à 3:22 PM, Dan Smith a écrit :

Hi Aashita,

The mailing lists are self service, please send an email to
user-subscr...@geode.apache.org.

http://geode.apache.org/community/#mailing-lists

-Dan

On Fri, May 5, 2017 at 2:41 PM, Aashita Sharma <
aashitasha...@yahoo.co.in.invalid> wrote:


Hello,
Request you to help me subscribe or register to  Mailing Lists so that if
I come across any issue while developing my code, I'll be having some help
to resolve it.

|
|
|
|   ||

|

   |
|
|   |
Mailing Lists
  Home page of The Apache Software Foundation  |   |

   |

   |


  Regards,  Aashita

Review Request 59034: GEODE-2352 Document that REST API requires two properties

2017-05-05 Thread Dave Barnes


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

Review request for geode, Hitesh Khamesra, Joey McAllister, and Pulkit Chandra.


Repository: geode


Description
---

GEODE-2352 Document that REST API requires two properties


Diffs
-

  geode-docs/rest_apps/chapter_overview.html.md.erb 
5e48675b7eba37ae3f6cd078111c0acf09d9ae68 
  geode-docs/rest_apps/rest_prereqs.html.md.erb 
935f94b2caf83478bd0ac97dc797ccdcee695b8c 
  geode-docs/rest_apps/setup_config.html.md.erb 
71c50f53dbc080f9d973b268eade9cb03c05e746 


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


Testing
---

The two properties, `http-service-bind-address` and `http-service-port`, are 
not *mandatory* as stated in the ticket, but if allowed to default, they may 
not be publicly visible. So we'll say they're optional, but that it's *good 
practice* to specify them for visibility.
This checkin also picks up some other corrections regarding API library name 
and some format fixes.


Thanks,

Dave Barnes

Re: Development Help!

2017-05-05 Thread Dan Smith

Hi Aashita,

The mailing lists are self service, please send an email to
user-subscr...@geode.apache.org.

http://geode.apache.org/community/#mailing-lists

-Dan

On Fri, May 5, 2017 at 2:41 PM, Aashita Sharma <
aashitasha...@yahoo.co.in.invalid> wrote:

> Hello,
> Request you to help me subscribe or register to  Mailing Lists so that if
> I come across any issue while developing my code, I'll be having some help
> to resolve it.
>
> |
> |
> |
> |   ||
>
>|
>
>   |
> |
> |   |
> Mailing Lists
>  Home page of The Apache Software Foundation  |   |
>
>   |
>
>   |
>
>
>  Regards,  Aashita

[jira] [Commented] (GEODE-2885) Client users need an easy way to check on server

2017-05-05 Thread Fred Krone (JIRA)


[ 
https://issues.apache.org/jira/browse/GEODE-2885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999044#comment-15999044
 ] 

Fred Krone commented on GEODE-2885:
---

Current local/client only Region methods
-- should "onServer" methods be added for these?

RegionAttributes getAttributes();
-- no: should always be local attributes

AttributesMutator getAttributesMutator();
-- no: should always be local attributes mutator

CacheStatistics getStatistics();
-- no: should be local

Entry getEntry(Object key);
maybe

Region getSubregion(String path);
no: should always be subregion in the local cache

Set subregions(boolean recursive);
no: should always be subregions that exist in the local cache

public Set keySet();
 yes: already implemented as keySetOnServer

Collection values();
maybe

Set entrySet(boolean recursive);
maybe

Set> entrySet();
maybe

Object getUserAttribute();
no: should always be local

void setUserAttribute(Object value);
no: should always be local

boolean isDestroyed();
no: should always be local

containsValueForKey(Object key);
should be same as getEntry
  
boolean containsKey(Object key);
 should be same as getEntry: already implemented as containsKeyOnServer
 
boolean containsValue(Object value);
maybe

boolean isEmpty();
yes: same as size

int size();
yes

void forEach(BiConsumer action)
same as entrySet
  
void replaceAll(BiFunction function)
same as entrySet





> Client users need an easy way to check on server
> 
>
> Key: GEODE-2885
> URL: https://issues.apache.org/jira/browse/GEODE-2885
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Fred Krone
>
> When "getting" a region from the client, and putting or getting to that 
> region, certain methods can be very confusing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2886) The WaitUntilFlushedFunction throws an IllegalArgumentException instead of an IllegalStateException

2017-05-05 Thread Barry Oglesby (JIRA)

Barry Oglesby created GEODE-2886:


 Summary: The WaitUntilFlushedFunction throws an 
IllegalArgumentException instead of an IllegalStateException
 Key: GEODE-2886
 URL: https://issues.apache.org/jira/browse/GEODE-2886
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Barry Oglesby


When the AEQ doesn't exist, the WaitUntilFlushedFunction throws an 
IllegalArgumentException like:
{noformat}
Caused by: java.lang.IllegalArgumentException: The AEQ does not exist for the 
index xxx region /yyy
at 
org.apache.geode.cache.lucene.internal.distributed.WaitUntilFlushedFunction.execute(WaitUntilFlushedFunction.java:89)
at 
org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:333)
{noformat}
The arguments are actually fine so should it instead throw an 
IllegalStateException?





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (GEODE-2858) Add test to verify successful load of configuration with pool or locator


[ 
https://issues.apache.org/jira/browse/GEODE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999038#comment-15999038
 ] 

Kirk Lund edited comment on GEODE-2858 at 5/5/17 10:12 PM:
---

I discovered and filed GEODE-2884 while testing GEODE-2858. I'll be committing 
the fix for GEODE-2884 along with the new test Oleg provided in PR #397.


was (Author: klund):
I discovered and filed GEODE-2884 while testing GEODE-2858. I'll be committing 
the fix GEODE-2884 along with the new test Oleg provided in PR #397.

> Add test to verify successful load of configuration with pool or locator
> 
>
> Key: GEODE-2858
> URL: https://issues.apache.org/jira/browse/GEODE-2858
> Project: Geode
>  Issue Type: Test
>  Components: client/server, locator
>Reporter: Oleg
>Assignee: Kirk Lund
>Priority: Minor
>
> Geode 0.9 / Gemfire 9.0 had a regression where it could not load config xml 
> file with pool or locator configuration in it.  It was fixed in 1.0 but no 
> test was added.  Add a unit test to prevent this coming back.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2858) Add test to verify successful load of configuration with pool or locator

2017-05-05 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/GEODE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999038#comment-15999038
 ] 

Kirk Lund commented on GEODE-2858:
--

I discovered and filed GEODE-2884 while testing GEODE-2858. I'll be committing 
the fix GEODE-2884 along with the new test Oleg provided in PR #397.

> Add test to verify successful load of configuration with pool or locator
> 
>
> Key: GEODE-2858
> URL: https://issues.apache.org/jira/browse/GEODE-2858
> Project: Geode
>  Issue Type: Test
>  Components: client/server, locator
>Reporter: Oleg
>Assignee: Kirk Lund
>Priority: Minor
>
> Geode 0.9 / Gemfire 9.0 had a regression where it could not load config xml 
> file with pool or locator configuration in it.  It was fixed in 1.0 but no 
> test was added.  Add a unit test to prevent this coming back.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2885) Client users need an easy way to check on server

2017-05-05 Thread Fred Krone (JIRA)

Fred Krone created GEODE-2885:
-

 Summary: Client users need an easy way to check on server
 Key: GEODE-2885
 URL: https://issues.apache.org/jira/browse/GEODE-2885
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Fred Krone


When "getting" a region from the client, and putting or getting to that region, 
certain methods can be very confusing.





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-1996) There are confusing references to "multicast" for locators ports


[ 
https://issues.apache.org/jira/browse/GEODE-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999032#comment-15999032
 ] 

ASF subversion and git services commented on GEODE-1996:


Commit 9e089c5ebbb14c989b370d20f47ca4f5c69a9c00 in geode's branch 
refs/heads/feature/GEODE-2858 from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=9e089c5 ]

GEODE-1996 Confusing references to "multicast" for locators ports


> There are confusing references to "multicast" for locators ports
> 
>
> Key: GEODE-1996
> URL: https://issues.apache.org/jira/browse/GEODE-1996
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Udo Kohlmeyer
>Assignee: Dave Barnes
> Fix For: 1.2.0
>
>
> The documentation seems to contain confusing terms when it comes to locators 
> and locators ports. In the documentation, we state that port the locator runs 
> on as a *multicast* port. This is incorrect as the multicast port is 
> configured by the property `mcast-port`.
> http://geode.apache.org/docs/guide/11/configuring/running/firewalls_ports.html
>  - mentions ??By default, if not otherwise specified, Geode locators use the 
> default multicast port 10334.??
> We might have to scour the documentation for the term multicast and validate 
> that this is the correct usage for that scenario



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2884) ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if called before getLatest()

2017-05-05 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/GEODE-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999034#comment-15999034
 ] 

ASF subversion and git services commented on GEODE-2884:


Commit 01cd587a8affa03948d54ca4ef49de311d76314a in geode's branch 
refs/heads/feature/GEODE-2858 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=01cd587 ]

GEODE-2884: fix NPE when calling getLatestAsClassLoader before getLatest

Without this fix, CacheXmlParserJUnitTest.testGetDelegate() fails when
run in isolation but passes when run with all tests.


> ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if 
> called before getLatest()
> -
>
> Key: GEODE-2884
> URL: https://issues.apache.org/jira/browse/GEODE-2884
> Project: Geode
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if 
> called before getLatest(). This manifests itself if you run 
> CacheXmlParserJUnitTest in isolation.
> {noformat}
> java.lang.NullPointerException
>   at 
> org.apache.geode.internal.ClassPathLoader.getLatestAsClassLoader(ClassPathLoader.java:372)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.getDelegate(CacheXmlParser.java:2770)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParserJUnitTest$TestCacheXmlParser.getDelegate(CacheXmlParserJUnitTest.java:174)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParserJUnitTest.testGetDelegate(CacheXmlParserJUnitTest.java:67)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>   at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2858) Add test to verify successful load of configuration with pool or locator

2017-05-05 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/GEODE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999033#comment-15999033
 ] 

ASF subversion and git services commented on GEODE-2858:


Commit ee9011943d8a2f9892e77bb4b27bf6e41fe91339 in geode's branch 
refs/heads/feature/GEODE-2858 from [~oshvarts]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=ee90119 ]

GEODE-2858: Add test for parsing of simple XML file w pool

to detect/prevent regression to parsing exceptions that
was fixed in Geode 1.0

This closes #397


> Add test to verify successful load of configuration with pool or locator
> 
>
> Key: GEODE-2858
> URL: https://issues.apache.org/jira/browse/GEODE-2858
> Project: Geode
>  Issue Type: Test
>  Components: client/server, locator
>Reporter: Oleg
>Assignee: Kirk Lund
>Priority: Minor
>
> Geode 0.9 / Gemfire 9.0 had a regression where it could not load config xml 
> file with pool or locator configuration in it.  It was fixed in 1.0 but no 
> test was added.  Add a unit test to prevent this coming back.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 58682: GEODE-2662: Missing keys cause columns to shift in gfsh table display.


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




geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
Line 91 (original)


We should be using log4j levels, so restore this line. All of the 
"fineEnabled" and "logger.fine" should be "logger.isTraceEnabled" and 
"logger.trace"

Then remove all the local declarations of:

   LogWriter logger = cache.getLogger();


- Ken Howe


On May 5, 2017, 9:22 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58682/
> ---
> 
> (Updated May 5, 2017, 9:22 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added unittests to capture failing behavior.
> 
> Corrected buildTable shifting columns when adding values with additional keys.
> 
> 
> Refactoring of DataCommandResult and DataCommandFunction
> 
> --
> 
> The majority of changes to DataCommandFunction and DataCommandResult are 
> refactoring.  Two ignored exceptions have been explicitly noted in the logger.
> 
> - In DataCommandFunction:423, there's an empty if block.  I imagine I should 
> remove that, since empty code is a waste.  Looking for it, I couldn't find 
> the comment-hinted separate method, though. Anyone familiar with this corner 
> of the code know if that actuall happens?
> 
> - Qualitative changes are in DataCommandResult.buildTable.  Items in the 
> table are scanned to build an agggregate key set, and those items missing any 
> of these keys are padded with `MISSING_VALUE`.
> 
> - I moved some of the more cumbersome blocks of code to subfunctions, but may 
> have done this more than necessary.  Opinions?
> 
> - Introduced DataCommandFunctionWithPDXJUnitTest to explicitly drive 
> development / note the bug in GEODE-2662.  Are there additional tests that 
> would fit naturally in this file?
> 
> 
> Diffs
> -
> 
>   geode-core/build.gradle f07444a 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
>  29d68bd 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/DataCommandResult.java
>  423d781 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DataCommandFunction.java
>  bb77466 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/TabularResultData.java
>  e72654e 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryDataInconsistencyDUnitTest.java
>  1af6261 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/GemfireDataCommandsDUnitTest.java
>  0e2a41e 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DataCommandFunctionWithPDXJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  ead1047 
> 
> 
> Diff: https://reviews.apache.org/r/58682/diff/7/
> 
> 
> Testing
> ---
> 
> Previous precheckin returned fully green.  Running with new refactoring but 
> expect no issues.  (Common last words.)
> 
> 
> Thanks,
> 
> Patrick Rhomberg
> 
>

[jira] [Resolved] (GEODE-1996) There are confusing references to "multicast" for locators ports


 [ 
https://issues.apache.org/jira/browse/GEODE-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Barnes resolved GEODE-1996.

   Resolution: Fixed
Fix Version/s: 1.2.0

> There are confusing references to "multicast" for locators ports
> 
>
> Key: GEODE-1996
> URL: https://issues.apache.org/jira/browse/GEODE-1996
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Udo Kohlmeyer
>Assignee: Dave Barnes
> Fix For: 1.2.0
>
>
> The documentation seems to contain confusing terms when it comes to locators 
> and locators ports. In the documentation, we state that port the locator runs 
> on as a *multicast* port. This is incorrect as the multicast port is 
> configured by the property `mcast-port`.
> http://geode.apache.org/docs/guide/11/configuring/running/firewalls_ports.html
>  - mentions ??By default, if not otherwise specified, Geode locators use the 
> default multicast port 10334.??
> We might have to scour the documentation for the term multicast and validate 
> that this is the correct usage for that scenario



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Review Request 59032: GEODE-2882: Throw RegionDestroyedException instead of IllegalStateException when region is destroyed

2017-05-05 Thread Eric Shu


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

Review request for geode, anilkumar gingade, Darrel Schneider, and Lynn 
Gallinat.


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


Repository: geode


Description
---

Throw RegionDestroyedException instead of IllegalStateException when region is 
destroyed


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegion.java 
da80fa6 
  
geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegionHelper.java
 08dac6e 


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


Testing
---

precheckin


Thanks,

Eric Shu

[jira] [Updated] (GEODE-2884) ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if called before getLatest()


 [ 
https://issues.apache.org/jira/browse/GEODE-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-2884:
-
Affects Version/s: 1.0.0-incubating
   1.1.0
   1.1.1

> ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if 
> called before getLatest()
> -
>
> Key: GEODE-2884
> URL: https://issues.apache.org/jira/browse/GEODE-2884
> Project: Geode
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if 
> called before getLatest(). This manifests itself if you run 
> CacheXmlParserJUnitTest in isolation.
> {noformat}
> java.lang.NullPointerException
>   at 
> org.apache.geode.internal.ClassPathLoader.getLatestAsClassLoader(ClassPathLoader.java:372)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.getDelegate(CacheXmlParser.java:2770)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParserJUnitTest$TestCacheXmlParser.getDelegate(CacheXmlParserJUnitTest.java:174)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParserJUnitTest.testGetDelegate(CacheXmlParserJUnitTest.java:67)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>   at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2884) ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if called before getLatest()

Kirk Lund created GEODE-2884:


 Summary: ClassPathLoader.getLatestAsClassLoader() throws 
NullPointerException if called before getLatest()
 Key: GEODE-2884
 URL: https://issues.apache.org/jira/browse/GEODE-2884
 Project: Geode
  Issue Type: Bug
  Components: core
Reporter: Kirk Lund


ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if called 
before getLatest(). This manifests itself if you run CacheXmlParserJUnitTest in 
isolation.
{noformat}
java.lang.NullPointerException
at 
org.apache.geode.internal.ClassPathLoader.getLatestAsClassLoader(ClassPathLoader.java:372)
at 
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.getDelegate(CacheXmlParser.java:2770)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.apache.geode.internal.cache.xmlcache.CacheXmlParserJUnitTest$TestCacheXmlParser.getDelegate(CacheXmlParserJUnitTest.java:174)
at 
org.apache.geode.internal.cache.xmlcache.CacheXmlParserJUnitTest.testGetDelegate(CacheXmlParserJUnitTest.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at 
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
at 
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2884) ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if called before getLatest()

2017-05-05 Thread ASF subversion and git services (JIRA)


 [ 
https://issues.apache.org/jira/browse/GEODE-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund reassigned GEODE-2884:


Assignee: Kirk Lund

> ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if 
> called before getLatest()
> -
>
> Key: GEODE-2884
> URL: https://issues.apache.org/jira/browse/GEODE-2884
> Project: Geode
>  Issue Type: Bug
>  Components: core
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if 
> called before getLatest(). This manifests itself if you run 
> CacheXmlParserJUnitTest in isolation.
> {noformat}
> java.lang.NullPointerException
>   at 
> org.apache.geode.internal.ClassPathLoader.getLatestAsClassLoader(ClassPathLoader.java:372)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.getDelegate(CacheXmlParser.java:2770)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParserJUnitTest$TestCacheXmlParser.getDelegate(CacheXmlParserJUnitTest.java:174)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParserJUnitTest.testGetDelegate(CacheXmlParserJUnitTest.java:67)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>   at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-1996) There are confusing references to "multicast" for locators ports


[ 
https://issues.apache.org/jira/browse/GEODE-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999005#comment-15999005
 ] 

ASF subversion and git services commented on GEODE-1996:


Commit 9e089c5ebbb14c989b370d20f47ca4f5c69a9c00 in geode's branch 
refs/heads/develop from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=9e089c5 ]

GEODE-1996 Confusing references to "multicast" for locators ports


> There are confusing references to "multicast" for locators ports
> 
>
> Key: GEODE-1996
> URL: https://issues.apache.org/jira/browse/GEODE-1996
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Udo Kohlmeyer
>Assignee: Dave Barnes
>
> The documentation seems to contain confusing terms when it comes to locators 
> and locators ports. In the documentation, we state that port the locator runs 
> on as a *multicast* port. This is incorrect as the multicast port is 
> configured by the property `mcast-port`.
> http://geode.apache.org/docs/guide/11/configuring/running/firewalls_ports.html
>  - mentions ??By default, if not otherwise specified, Geode locators use the 
> default multicast port 10334.??
> We might have to scour the documentation for the term multicast and validate 
> that this is the correct usage for that scenario



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2738) Occurred is spelled with two Rs.


[ 
https://issues.apache.org/jira/browse/GEODE-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998995#comment-15998995
 ] 

ASF GitHub Bot commented on GEODE-2738:
---

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/435
  
Re-rebased and conflict resolved.


> Occurred is spelled with two Rs.
> 
>
> Key: GEODE-2738
> URL: https://issues.apache.org/jira/browse/GEODE-2738
> Project: Geode
>  Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Trivial
>
> Most frequently, "an exception occured: {}" in logging.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #435: GEODE-2738: Corrected spelling of "occured" to occurred

2017-05-05 Thread PurelyApplied

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/435
  
Re-rebased and conflict resolved.


---
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 58682: GEODE-2662: Missing keys cause columns to shift in gfsh table display.

2017-05-05 Thread Patrick Rhomberg

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

(Updated May 5, 2017, 9:22 p.m.)

Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, and
Swapnil Bawaskar.

Changes
---

A couple critical "cleanups" went from (x != null ...) to (Util.isEmpty(x)).
Whoops.

Repository: geode

Description
---

Added unittests to capture failing behavior.

Corrected buildTable shifting columns when adding values with additional keys.

Refactoring of DataCommandResult and DataCommandFunction

The majority of changes to DataCommandFunction and DataCommandResult are
refactoring. Two ignored exceptions have been explicitly noted in the logger.

- In DataCommandFunction:423, there's an empty if block. I imagine I should
remove that, since empty code is a waste. Looking for it, I couldn't find the
comment-hinted separate method, though. Anyone familiar with this corner of the
code know if that actuall happens?

- Qualitative changes are in DataCommandResult.buildTable. Items in the table
are scanned to build an agggregate key set, and those items missing any of
these keys are padded with `MISSING_VALUE`.

- I moved some of the more cumbersome blocks of code to subfunctions, but may
have done this more than necessary. Opinions?

- Introduced DataCommandFunctionWithPDXJUnitTest to explicitly drive
development / note the bug in GEODE-2662. Are there additional tests that
would fit naturally in this file?

Diffs (updated)
-

geode-core/build.gradle f07444a

geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
29d68bd

geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/DataCommandResult.java
423d781

geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DataCommandFunction.java
bb77466

geode-core/src/main/java/org/apache/geode/management/internal/cli/result/TabularResultData.java
e72654e

geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryDataInconsistencyDUnitTest.java
1af6261

geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/GemfireDataCommandsDUnitTest.java
0e2a41e

geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DataCommandFunctionWithPDXJUnitTest.java
PRE-CREATION

geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
ead1047

Diff: https://reviews.apache.org/r/58682/diff/7/

Changes: https://reviews.apache.org/r/58682/diff/6-7/

Testing
---

Previous precheckin returned fully green. Running with new refactoring but
expect no issues. (Common last words.)

Thanks,

Patrick Rhomberg

Re: Review Request 59027: GEODE-1996 Confusing references to "multicast" for locators ports

2017-05-05 Thread Joey McAllister


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


Fix it, then Ship it!




Fix it, then ship it.


geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb
Lines 54 (patched)


I think this "remote" is still referring to this contextual definition of 
the word, right? If so, it should go in quotes, too.



geode-docs/managing/monitor_tune/udp_communication.html.md.erb
Lines 44 (patched)


hyphenate "flow-control protocol"


- Joey McAllister


On May 5, 2017, 3:49 p.m., Dave Barnes wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59027/
> ---
> 
> (Updated May 5, 2017, 3:49 p.m.)
> 
> 
> Review request for geode, Joey McAllister and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1996 Confusing references to "multicast" for locators ports
> 
> 
> Diffs
> -
> 
>   
> geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb
>  a06a8c81cd12260f7384a202a4a0d5643806a367 
>   geode-docs/configuring/running/firewalls_ports.html.md.erb 
> 11e4554887cbc845b881ad61959d2a4345bb0c8a 
>   
> geode-docs/managing/monitor_tune/multicast_communication_runtime_considerations.html.md.erb
>  77fd42b9c043b613c8dcf68feda0bd49d482cd1a 
>   
> geode-docs/managing/monitor_tune/socket_communication_ephemeral_tcp_port_limits.html.md.erb
>  3df570a3859f1b49874f682b9639e642584666c2 
>   
> geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb
>  a075e08533e74ae986db9efde552c392cd5cce2c 
>   
> geode-docs/managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html.md.erb
>  41884a2ecc21f607a91eb8910b001be77aa1ad6a 
>   
> geode-docs/managing/monitor_tune/socket_communication_tcpip_p2p_handshake_timeouts.html.md.erb
>  486c337092382f9bde702e677ba1122583cff440 
>   geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb 
> ca20bf81dbccaad1beaa52b064db1e1644de86e6 
>   geode-docs/managing/monitor_tune/udp_communication.html.md.erb 
> 4a5d3c0bf8f24275a4040e8f0f1926a06e990b7f 
>   geode-docs/reference/statistics/statistics_list.html.md.erb 
> 7f7b76f79e944ffc495f8974712b1c53b9863a55 
>   geode-docs/tools_modules/gfsh/command-pages/connect.html.md.erb 
> c83d2ffe92c7784b5f41b63e879a3199a26ee88a 
> 
> 
> Diff: https://reviews.apache.org/r/59027/diff/1/
> 
> 
> Testing
> ---
> 
> Corrected two references to the locator's "multicast port" as described in 
> the JIRA ticket. Searched the entire user guide, found no other occurrences. 
> In the process, corrected some typos and formatting issues, which are 
> included in this checkin to save the overhead of creating a separate ticket 
> and review cycle.
> 
> 
> Thanks,
> 
> Dave Barnes
> 
>

[jira] [Assigned] (GEODE-2858) Add test to verify successful load of configuration with pool or locator


 [ 
https://issues.apache.org/jira/browse/GEODE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund reassigned GEODE-2858:


Assignee: Kirk Lund

> Add test to verify successful load of configuration with pool or locator
> 
>
> Key: GEODE-2858
> URL: https://issues.apache.org/jira/browse/GEODE-2858
> Project: Geode
>  Issue Type: Test
>  Components: client/server, locator
>Reporter: Oleg
>Assignee: Kirk Lund
>Priority: Minor
>
> Geode 0.9 / Gemfire 9.0 had a regression where it could not load config xml 
> file with pool or locator configuration in it.  It was fixed in 1.0 but no 
> test was added.  Add a unit test to prevent this coming back.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2815) Incorrect Error Message in REST API docs for {region}/{key} HTTP.GET command

2017-05-05 Thread ASF subversion and git services (JIRA)


 [ 
https://issues.apache.org/jira/browse/GEODE-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Barnes reassigned GEODE-2815:
--

Assignee: Dave Barnes

> Incorrect Error Message in REST API docs for {region}/{key} HTTP.GET command
> 
>
> Key: GEODE-2815
> URL: https://issues.apache.org/jira/browse/GEODE-2815
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Affects Versions: 1.1.1, 1.2.0
>Reporter: Michael Martell
>Assignee: Dave Barnes
>Priority: Minor
>
> According to the docs at 
> http://gemfire.docs.pivotal.io/geode/rest_apps/get_region_key_data.html error 
> responses HTTP 400 and HTTP 404 appear to be very similar,
> # 400 - BAD REQUEST - Returned if the supplied key is not found in the region.
> # 404 - NOT FOUND - Returned if key does not exist for the region.
> The source code at PdxBasedCrudController.java:210 & 213 show that 404 
> actually means "Region does not exist", thus the documentation appears to be 
> incorrect. Other commands are correct in the docs showing 404 means region 
> does not exist.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [gemfire-dev] New Client-Server Protocol Proposal

2017-05-05 Thread Hitesh Khamesra


0. In first phase we are not doing chunking/fragmentation. And even this will 
be option for 
client.(https://cwiki.apache.org/confluence/display/GEODE/Message+Structure+and+Definition#MessageStructureandDefinition-Protocolnegotiation)
1. Are you refereeing websocket/spdy? But I think we are talking almost same 
thing, may be push isPartialMessage flag with chunk length(Anthony's example 
below) ?
2. That's the part of the problem. Even if you need to serialize the "String", 
you need to write length first and then need to write serialized utf bytes. We 
can implement chunked input stream and can de-serialize the object as it is 
coming (DataSerializable.fromData(ChunkedStream)). 




  From: Jacob Barrett 
 To: dev@geode.apache.org; Hitesh Khamesra  
Cc: Anthony Baker 
 Sent: Friday, May 5, 2017 7:29 AM
 Subject: Re: [gemfire-dev] New Client-Server Protocol Proposal
   

On Thu, May 4, 2017 at 2:52 PM Hitesh Khamesra  
wrote:

Basically, thread/layer should not hold any resources while serializing the 
object or chunk.  We should be able to see this flow (ms1-chunk1, msg2-chunk1, 
ms1-chunk2, msg3-chunk, msg2-chunk2, so on ...)


Correct, but putting that in the message layer is not appropriate. The simple 
solution is that the multiple channels can be achieved with multiple sockets. 
The later optimization is to add a channel multiplexer layer between the 
message and socket layers. 
If we put it in the message layer, not only does it for the message to tackle 
something it shouldn't be concerned with, reassembling itself, but it also 
forces all implementors to tackle this logic up front. By layering we can 
release without, implementors aren't forced into understanding the logic, and 
later we can release the layers and the client can negotiate.
 
On other pdx note: to de-serialize the pdx we need length of serialized bytes, 
so that we can read field offset from serialized stream, and then can read 
field value. Though, I can imagine with the help of pdxType, we can interpret 
serialized stream.


Yes, so today PDX serialization would be no worse, the PDX serializer would 
have to buffer, but other may not have to. The length of the buffered PDX could 
be used as the first chunk length and complete in single chunk. Although, I 
suspect that amortized overhead of splitting the chunks  will be nil anyway. 
The point is that the message encoding of values should NOT have any unbounded 
length fields and require long or many buffers to complete serialization. By 
chunking you can accomplish this by not needing to buffer the whole stream, 
just small (say 1k), chunks at a time to get the chunk length. 
Buffers == Latency
-Jake

[jira] [Assigned] (GEODE-2882) An IllegalStateException: attempting to hash null is thrown during transactional putAll when region is destroyed

2017-05-05 Thread Eric Shu (JIRA)


 [ 
https://issues.apache.org/jira/browse/GEODE-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Shu reassigned GEODE-2882:
---

Assignee: Eric Shu

> An IllegalStateException: attempting to hash null is thrown during 
> transactional putAll when region is destroyed
> 
>
> Key: GEODE-2882
> URL: https://issues.apache.org/jira/browse/GEODE-2882
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>
> Bellow is the stack that throws the Exception.
> {noformat}
> util.TestException: java.lang.IllegalStateException: attempting to hash null
> at 
> com.gemstone.gemfire.internal.cache.PartitionedRegionHelper.getHashKey(PartitionedRegionHelper.java:618)
> at 
> com.gemstone.gemfire.internal.cache.PartitionedRegionHelper.getHashKey(PartitionedRegionHelper.java:522)
> at 
> com.gemstone.gemfire.internal.cache.PartitionedRegion.getOwnerForKey(PartitionedRegion.java:10035)
> at 
> com.gemstone.gemfire.internal.cache.TXStateProxyImpl.getRealDeal(TXStateProxyImpl.java:153)
> at 
> com.gemstone.gemfire.internal.cache.TXStateProxyImpl.postRemoveAll(TXStateProxyImpl.java:953)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.basicRemoveAll(LocalRegion.java:10413)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.removeAll(LocalRegion.java:9989)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2883) gfsh gc reports incorrect heap sizes

2017-05-05 Thread Barry Oglesby (JIRA)

Barry Oglesby created GEODE-2883:


 Summary: gfsh gc reports incorrect heap sizes
 Key: GEODE-2883
 URL: https://issues.apache.org/jira/browse/GEODE-2883
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Barry Oglesby


I have 3 servers each with -Xms1g and -Xmx1g, and I load some data.

If I run a gfsh gc, it reports:
{noformat}
GC Summary

  Member ID/Name| HeapSize (MB) Before GC | HeapSize(MB) After GC | 
Time Taken for GC in ms
--- | --- | - | 
---
192.168.2.7(98588):1025 | 2078| 1098  | 
516
192.168.2.7(98602):1027 | 1942| 1110  | 
530
192.168.2.7(98595):1026 | 2019| 1109  | 
531
{noformat}
The heap sizes before and after are higher than they should be.

I added some debugging in the GarbageCollectionFunction, and it shows:
{noformat}
GarbageCollectionFunction.execute freeMemoryBeforeGC=765581248; 
totalMemoryBeforeGC=1037959168
GarbageCollectionFunction.execute freeMemoryAfterGC=893946464; 
totalMemoryAfterGC=1037959168
GarbageCollectionFunction.execute HeapSizeBeforeGC=2078
GarbageCollectionFunction.execute HeapSizeAfterGC=1098

GarbageCollectionFunction.execute freeMemoryBeforeGC=773307528; 
totalMemoryBeforeGC=1037959168
GarbageCollectionFunction.execute freeMemoryAfterGC=892508088; 
totalMemoryAfterGC=1037959168
GarbageCollectionFunction.execute HeapSizeBeforeGC=2019
GarbageCollectionFunction.execute HeapSizeAfterGC=1109

GarbageCollectionFunction.execute freeMemoryBeforeGC=783373464; 
totalMemoryBeforeGC=1037959168
GarbageCollectionFunction.execute freeMemoryAfterGC=892349664; 
totalMemoryAfterGC=1037959168
GarbageCollectionFunction.execute HeapSizeBeforeGC=1942
GarbageCollectionFunction.execute HeapSizeAfterGC=1110
{noformat}
The free and total memory are fine, but the heap sizes before and after are 
incorrect.

The function is using 131072 as its divisor
{noformat}
1037959168-765581248=272377920 / 131072 = 2078
1037959168-893946464=144012704 / 131072 = 1098
{noformat}
It should be using 1024*1024.
{noformat}
1037959168-765581248=272377920 / (1024*1024) = 259
1037959168-893946464=144012704 / (1024*1024) = 137
{noformat}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2882) An IllegalStateException: attempting to hash null is thrown during transactional putAll when region is destroyed

2017-05-05 Thread Eric Shu (JIRA)

Eric Shu created GEODE-2882:
---

 Summary: An IllegalStateException: attempting to hash null is 
thrown during transactional putAll when region is destroyed
 Key: GEODE-2882
 URL: https://issues.apache.org/jira/browse/GEODE-2882
 Project: Geode
  Issue Type: Bug
  Components: regions
Reporter: Eric Shu


Bellow is the stack that throws the Exception.
{noformat}
util.TestException: java.lang.IllegalStateException: attempting to hash null
at 
com.gemstone.gemfire.internal.cache.PartitionedRegionHelper.getHashKey(PartitionedRegionHelper.java:618)
at 
com.gemstone.gemfire.internal.cache.PartitionedRegionHelper.getHashKey(PartitionedRegionHelper.java:522)
at 
com.gemstone.gemfire.internal.cache.PartitionedRegion.getOwnerForKey(PartitionedRegion.java:10035)
at 
com.gemstone.gemfire.internal.cache.TXStateProxyImpl.getRealDeal(TXStateProxyImpl.java:153)
at 
com.gemstone.gemfire.internal.cache.TXStateProxyImpl.postRemoveAll(TXStateProxyImpl.java:953)
at 
com.gemstone.gemfire.internal.cache.LocalRegion.basicRemoveAll(LocalRegion.java:10413)
at 
com.gemstone.gemfire.internal.cache.LocalRegion.removeAll(LocalRegion.java:9989)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 58996: GEODE-2876: Add logging to diagnose CI failure

2017-05-05 Thread Jinmei Liao



> On May 4, 2017, 5:29 p.m., Jinmei Liao wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
> > Line 124 (original), 125 (patched)
> > 
> >
> > we are not showing info level logging in our current logs?
> > 
> > Also the best place to see what's being actually parsed is in 
> > GfshParser.parse method. That's where we are handing the input string to 
> > SpringShell's parsing method.
> 
> Jared Stewart wrote:
> I think this really does belong at "warning" level.  (If a user tries to 
> execute a command that can't be parsed, I think that should still be logged 
> even if they have set the log-level to WARN.)  That said, I'm a bit puzzled 
> by the current behavior.  The log statement does show up in the log, but it 
> appears to be missing the accompanying stack trace.
> ```
> [vm3] Command result for  --jar=/tmp/junit3108566533782045832/jar1.jar>: 
> [vm3] Could not parse command string. deploy 
> --jar=/tmp/junit3108566533782045832/jar1.jar
> ```
> 
> The other change should fix this by passing the full stacktrace back to 
> the client in the gfsh ErrorResult.  (I think this would also make it easier 
> for a real user either to diagnose their failure or to file a descriptive bug 
> report.)

when failed to parse, there is no stacktrace thrown by Spring's SimpleParser, 
it just simply returns null. That's why I would like to get a log statement 
right before we pass the string to Spring's parser and see what it failed to 
parse. then we can write a simple unit tests to find out.


- Jinmei


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


On May 4, 2017, 5:12 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58996/
> ---
> 
> (Updated May 4, 2017, 5:12 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2876: Add logging to diagnose CI failure
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e1425d71af9d2ea59046b17afd70ad30dd68 
> 
> 
> Diff: https://reviews.apache.org/r/58996/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[jira] [Commented] (GEODE-2858) Add test to verify successful load of configuration with pool or locator


[ 
https://issues.apache.org/jira/browse/GEODE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998921#comment-15998921
 ] 

ASF subversion and git services commented on GEODE-2858:


Commit 15c87b79ac524423a27fa94616962792dd1d465c in geode's branch 
refs/heads/feature/GEODE-2858 from [~oshvarts]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=15c87b7 ]

GEODE-2858: Add test for parsing of simple XML file w pool

to detect/prevent regression to parsing exceptions that
was fixed in Geode 1.0

This closes #397


> Add test to verify successful load of configuration with pool or locator
> 
>
> Key: GEODE-2858
> URL: https://issues.apache.org/jira/browse/GEODE-2858
> Project: Geode
>  Issue Type: Test
>  Components: client/server, locator
>Reporter: Oleg
>Priority: Minor
>
> Geode 0.9 / Gemfire 9.0 had a regression where it could not load config xml 
> file with pool or locator configuration in it.  It was fixed in 1.0 but no 
> test was added.  Add a unit test to prevent this coming back.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (GEODE-1887) Client PROXY region should delegate all operations to server

2017-05-05 Thread Darrel Schneider (JIRA)


[ 
https://issues.apache.org/jira/browse/GEODE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998776#comment-15998776
 ] 

Darrel Schneider edited comment on GEODE-1887 at 5/5/17 6:52 PM:
-

The problem with changing the existing behavior of PROXY on a client is that it 
could break existing applications.
When Region methods are done on a client region then it must always decide what 
it will do with two possible spaces:
# the region state in the client space
# the region state in the server space

The following region methods limit themselves to the client space:
*  public RegionAttributes getAttributes();
*  public AttributesMutator getAttributesMutator();
*  public CacheStatistics getStatistics();
*  public Entry getEntry(Object key);
*  public  Region getSubregion(String path);
*  public Set subregions(boolean recursive);
*  public Set keySet();
*  public Collection values();
*  public Set entrySet(boolean recursive);
*  public Set> entrySet();
*  public Object getUserAttribute();
*  public void setUserAttribute(Object value);
*  public boolean isDestroyed();
*  public boolean containsValueForKey(Object key);
*  public boolean containsKey(Object key);
*  public boolean containsValue(Object value);
*  public boolean isEmpty();
*  public int size();
*  default void forEach(BiConsumer action)
*  default void replaceAll(BiFunction 
function)


Some of these (keySet and containsKey) already have corresponding methods that 
perform the same operation in the server space (keySetOnServer and 
containsKeyOnServer).
For at least some of the other client space methods I think we should also add 
"OnServer" methods. For example "sizeOnServer" and "isEmptyOnServer". I think 
it is easier for a develop to discover the "OnServer" method and it also tells 
them that a client has two different ways of answering the size question. These 
"OnServer" methods will fail with an UnsupportedOperationException if called on 
a non-client region. They will also completely ignore any client state. For 
example sizeOnServer will not consider any entries cached in the client but 
will simply report the size from the server's point of view.



was (Author: dschneider):
The problem with changing the existing behavior of PROXY on a client is that it 
could break existing applications.
When Region methods are done on a client region then it must always decide what 
it will do with two possible spaces:
  1. the region state in the client space
  2. the region state in the server space
The following region methods limit themselves to the client space:
*  public RegionAttributes getAttributes();
*  public AttributesMutator getAttributesMutator();
*  public CacheStatistics getStatistics();
*  public Entry getEntry(Object key);
*  public  Region getSubregion(String path);
*  public Set subregions(boolean recursive);
*  public Set keySet();
*  public Collection values();
*  public Set entrySet(boolean recursive);
*  public Set> entrySet();
*  public Object getUserAttribute();
*  public void setUserAttribute(Object value);
*  public boolean isDestroyed();
*  public boolean containsValueForKey(Object key);
*  public boolean containsKey(Object key);
*  public boolean containsValue(Object value);
*  public boolean isEmpty();
*  public int size();
*  default void forEach(BiConsumer action)
*  default void replaceAll(BiFunction 
function)


Some of these (keySet and containsKey) already have corresponding methods that 
perform the same operation in the server space (keySetOnServer and 
containsKeyOnServer).
For at least some of the other client space methods I think we should also add 
"OnServer" methods. For example "sizeOnServer" and "isEmptyOnServer". I think 
it is easier for a develop to discover the "OnServer" method and it also tells 
them that a client has two different ways of answering the size question. These 
"OnServer" methods will fail with an UnsupportedOperationException if called on 
a non-client region. They will also completely ignore any client state. For 
example sizeOnServer will not consider any entries cached in the client but 
will simply report the size from the server's point of view.


> Client PROXY region should delegate all operations to server
> 
>
> Key: GEODE-1887
> URL: https://issues.apache.org/jira/browse/GEODE-1887
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>Assignee: Avinash Dongre
>
> Currently a ClientRegionShortcut.PROXY region sends operations like put() and 
> get() over to the server, but for operations like size() and isEmpty() it 
> just consults the local state on the client

[jira] [Comment Edited] (GEODE-1887) Client PROXY region should delegate all operations to server

2017-05-05 Thread Darrel Schneider (JIRA)


[ 
https://issues.apache.org/jira/browse/GEODE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998776#comment-15998776
 ] 

Darrel Schneider edited comment on GEODE-1887 at 5/5/17 6:52 PM:
-

The problem with changing the existing behavior of PROXY on a client is that it 
could break existing applications.
When Region methods are done on a client region then it must always decide what 
it will do with two possible spaces:
  1. the region state in the client space
  2. the region state in the server space
The following region methods limit themselves to the client space:
*  public RegionAttributes getAttributes();
*  public AttributesMutator getAttributesMutator();
*  public CacheStatistics getStatistics();
*  public Entry getEntry(Object key);
*  public  Region getSubregion(String path);
*  public Set subregions(boolean recursive);
*  public Set keySet();
*  public Collection values();
*  public Set entrySet(boolean recursive);
*  public Set> entrySet();
*  public Object getUserAttribute();
*  public void setUserAttribute(Object value);
*  public boolean isDestroyed();
*  public boolean containsValueForKey(Object key);
*  public boolean containsKey(Object key);
*  public boolean containsValue(Object value);
*  public boolean isEmpty();
*  public int size();
*  default void forEach(BiConsumer action)
*  default void replaceAll(BiFunction 
function)


Some of these (keySet and containsKey) already have corresponding methods that 
perform the same operation in the server space (keySetOnServer and 
containsKeyOnServer).
For at least some of the other client space methods I think we should also add 
"OnServer" methods. For example "sizeOnServer" and "isEmptyOnServer". I think 
it is easier for a develop to discover the "OnServer" method and it also tells 
them that a client has two different ways of answering the size question. These 
"OnServer" methods will fail with an UnsupportedOperationException if called on 
a non-client region. They will also completely ignore any client state. For 
example sizeOnServer will not consider any entries cached in the client but 
will simply report the size from the server's point of view.



was (Author: dschneider):
The problem with changing the existing behavior of PROXY on a client is that it 
could break existing applications.
When Region methods are done on a client region then it must always decide what 
it will do with two possible spaces:
  1. the region state in the client space
  2. the region state in the server space
The following region methods limit themselves to the client space:
  public RegionAttributes getAttributes();
  public AttributesMutator getAttributesMutator();
  public CacheStatistics getStatistics();
  public Entry getEntry(Object key);
  public  Region getSubregion(String path);
  public Set subregions(boolean recursive);
  public Set keySet();
  public Collection values();
  public Set entrySet(boolean recursive);
  public Set> entrySet();
  public Object getUserAttribute();
  public void setUserAttribute(Object value);
  public boolean isDestroyed();
  public boolean containsValueForKey(Object key);
  public boolean containsKey(Object key);
  public boolean containsValue(Object value);
  public boolean isEmpty();
  public int size();
  default void forEach(BiConsumer action)
  default void replaceAll(BiFunction 
function)

Some of these (keySet and containsKey) already have corresponding methods that 
perform the same operation in the server space (keySetOnServer and 
containsKeyOnServer).
For at least some of the other client space methods I think we should also add 
"OnServer" methods. For example "sizeOnServer" and "isEmptyOnServer". I think 
it is easier for a develop to discover the "OnServer" method and it also tells 
them that a client has two different ways of answering the size question. These 
"OnServer" methods will fail with an UnsupportedOperationException if called on 
a non-client region. They will also completely ignore any client state. For 
example sizeOnServer will not consider any entries cached in the client but 
will simply report the size from the server's point of view.


> Client PROXY region should delegate all operations to server
> 
>
> Key: GEODE-1887
> URL: https://issues.apache.org/jira/browse/GEODE-1887
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>Assignee: Avinash Dongre
>
> Currently a ClientRegionShortcut.PROXY region sends operations like put() and 
> get() over to the server, but for operations like size() and isEmpty() it 
> just consults the local state on the client  and returns 0

[jira] [Commented] (GEODE-1887) Client PROXY region should delegate all operations to server

2017-05-05 Thread Darrel Schneider (JIRA)


[ 
https://issues.apache.org/jira/browse/GEODE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998776#comment-15998776
 ] 

Darrel Schneider commented on GEODE-1887:
-

The problem with changing the existing behavior of PROXY on a client is that it 
could break existing applications.
When Region methods are done on a client region then it must always decide what 
it will do with two possible spaces:
  1. the region state in the client space
  2. the region state in the server space
The following region methods limit themselves to the client space:
  public RegionAttributes getAttributes();
  public AttributesMutator getAttributesMutator();
  public CacheStatistics getStatistics();
  public Entry getEntry(Object key);
  public  Region getSubregion(String path);
  public Set subregions(boolean recursive);
  public Set keySet();
  public Collection values();
  public Set entrySet(boolean recursive);
  public Set> entrySet();
  public Object getUserAttribute();
  public void setUserAttribute(Object value);
  public boolean isDestroyed();
  public boolean containsValueForKey(Object key);
  public boolean containsKey(Object key);
  public boolean containsValue(Object value);
  public boolean isEmpty();
  public int size();
  default void forEach(BiConsumer action)
  default void replaceAll(BiFunction 
function)

Some of these (keySet and containsKey) already have corresponding methods that 
perform the same operation in the server space (keySetOnServer and 
containsKeyOnServer).
For at least some of the other client space methods I think we should also add 
"OnServer" methods. For example "sizeOnServer" and "isEmptyOnServer". I think 
it is easier for a develop to discover the "OnServer" method and it also tells 
them that a client has two different ways of answering the size question. These 
"OnServer" methods will fail with an UnsupportedOperationException if called on 
a non-client region. They will also completely ignore any client state. For 
example sizeOnServer will not consider any entries cached in the client but 
will simply report the size from the server's point of view.


> Client PROXY region should delegate all operations to server
> 
>
> Key: GEODE-1887
> URL: https://issues.apache.org/jira/browse/GEODE-1887
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>Assignee: Avinash Dongre
>
> Currently a ClientRegionShortcut.PROXY region sends operations like put() and 
> get() over to the server, but for operations like size() and isEmpty() it 
> just consults the local state on the client  and returns 0 and true 
> respectively, even though there may be data in the servers for that region.
> A PROXY region should not attempt to consult its local state for any 
> operation. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2877) Auth handler: "Cannot pass a GCHandle across AppDomains" in GemStone::GemFire::Cache::IAuthInitialize

2017-05-05 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/GEODE-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998773#comment-15998773
 ] 

ASF subversion and git services commented on GEODE-2877:


Commit 9c5db56265324e48af51daa5f84f692b2ae45f49 in geode-native's branch 
refs/heads/develop from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=9c5db56 ]

GEODE-2877: Fixes integration tests generation issues on Windows.

> Auth handler: "Cannot pass a GCHandle across AppDomains" in 
> GemStone::GemFire::Cache::IAuthInitialize
> -
>
> Key: GEODE-2877
> URL: https://issues.apache.org/jira/browse/GEODE-2877
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>
> If cache authentication module is initialized in AppDomain X and client in 
> AppDomain Y tries to authenticate then the callback results in a {{Cannot 
> pass a GCHandle across AppDomains}} error.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-258) Remove deprecated Cache.getLoggerI18n and getSecurityLoggerI18n methods


[ 
https://issues.apache.org/jira/browse/GEODE-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998723#comment-15998723
 ] 

ASF GitHub Bot commented on GEODE-258:
--

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/467
  
I think you should the log statements to use Log4j2 loggers instead of 
changing them to use a different getLogWriter() API. This work was started in 
2014 and was never finished.

To convert a class to use Logger, do the following:
```java
import org.apache.logging.log4j.Logger;
import org.apache.geode.internal.logging.LogService;
...
private static final Logger logger = LogService.getLogger();
```
And then change blocks like this:
```java
if ((logger != null) && logger.fineEnabled()) {
  logger.fine("RegionSubRegionSnapshot Region entry count =" + 
this.entryCount + " for region =" + this.name);
```

To this:
```java
if (logger.isDebugEnabled()) {
  logger.debug("RegionSubRegionSnapshot Region entry count ={} for region 
={}",  this.entryCount, this.name);
```


> Remove deprecated Cache.getLoggerI18n and getSecurityLoggerI18n methods
> ---
>
> Key: GEODE-258
> URL: https://issues.apache.org/jira/browse/GEODE-258
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Cache.getLoggerI18n and getSecurityLoggerI18n methods. 
> All calls can be replaced with getLogger().convertToLogWriterI18n() so this 
> should be a quick task.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #467: GEODE-258: Remove deprecated Cache.getLoggerI18n and getSe...

2017-05-05 Thread kirklund

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/467
  
I think you should the log statements to use Log4j2 loggers instead of 
changing them to use a different getLogWriter() API. This work was started in 
2014 and was never finished.

To convert a class to use Logger, do the following:
```java
import org.apache.logging.log4j.Logger;
import org.apache.geode.internal.logging.LogService;
...
private static final Logger logger = LogService.getLogger();
```
And then change blocks like this:
```java
if ((logger != null) && logger.fineEnabled()) {
  logger.fine("RegionSubRegionSnapshot Region entry count =" + 
this.entryCount + " for region =" + this.name);
```

To this:
```java
if (logger.isDebugEnabled()) {
  logger.debug("RegionSubRegionSnapshot Region entry count ={} for region 
={}",  this.entryCount, this.name);
```


---
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 58996: GEODE-2876: Add logging to diagnose CI failure



> On May 4, 2017, 5:29 p.m., Jinmei Liao wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
> > Line 124 (original), 125 (patched)
> > 
> >
> > we are not showing info level logging in our current logs?
> > 
> > Also the best place to see what's being actually parsed is in 
> > GfshParser.parse method. That's where we are handing the input string to 
> > SpringShell's parsing method.

I think this really does belong at "warning" level.  (If a user tries to 
execute a command that can't be parsed, I think that should still be logged 
even if they have set the log-level to WARN.)  That said, I'm a bit puzzled by 
the current behavior.  The log statement does show up in the log, but it 
appears to be missing the accompanying stack trace.
```
[vm3] Command result for : 
[vm3] Could not parse command string. deploy 
--jar=/tmp/junit3108566533782045832/jar1.jar
```

The other change should fix this by passing the full stacktrace back to the 
client in the gfsh ErrorResult.  (I think this would also make it easier for a 
real user either to diagnose their failure or to file a descriptive bug report.)


- Jared


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


On May 4, 2017, 5:12 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58996/
> ---
> 
> (Updated May 4, 2017, 5:12 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2876: Add logging to diagnose CI failure
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e1425d71af9d2ea59046b17afd70ad30dd68 
> 
> 
> Diff: https://reviews.apache.org/r/58996/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[jira] [Commented] (GEODE-1887) Client PROXY region should delegate all operations to server


[ 
https://issues.apache.org/jira/browse/GEODE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998720#comment-15998720
 ] 

ASF GitHub Bot commented on GEODE-1887:
---

Github user dschneider-pivotal commented on the issue:

https://github.com/apache/geode/pull/443
  
I think this pull request should be closed. GEODE-1887 will be updated with 
a plan for doing it without breaking backwards compatibility.



> Client PROXY region should delegate all operations to server
> 
>
> Key: GEODE-1887
> URL: https://issues.apache.org/jira/browse/GEODE-1887
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>Assignee: Avinash Dongre
>
> Currently a ClientRegionShortcut.PROXY region sends operations like put() and 
> get() over to the server, but for operations like size() and isEmpty() it 
> just consults the local state on the client  and returns 0 and true 
> respectively, even though there may be data in the servers for that region.
> A PROXY region should not attempt to consult its local state for any 
> operation. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #443: [GEODE-1887] #comment Fix for Client PROXY region should d...

2017-05-05 Thread dschneider-pivotal

Github user dschneider-pivotal commented on the issue:

https://github.com/apache/geode/pull/443
  
I think this pull request should be closed. GEODE-1887 will be updated with 
a plan for doing it without breaking backwards compatibility.



---
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: [gemfire-dev] New Client-Server Protocol Proposal

2017-05-05 Thread Jacob Barrett

In either case you packetize (serialize the message protocol) to buffers (fixed 
sizes and pooled) and flush buffers to the socket. Preferably using a async 
socket framework to do all the heavy lifting for you.


Sent from my iPhone

> On May 5, 2017, at 11:07 AM, Bruce Schuchardt  wrote:
> 
> Yes, of course it does but we don't serialize directly to a socket output 
> stream because it's slow.  I agree that this could be left out and added 
> later as an optimization.
> 
>> Le 5/5/2017 à 10:33 AM, Galen M O'Sullivan a écrit :
>> I think TCP does exactly this for us.
>> 
>> On Fri, May 5, 2017 at 9:08 AM, Bruce Schuchardt 
>> wrote:
>> 
>>> This is very similar to how peer-to-peer messaging is performed in Geode.
>>> Messages are serialized to a stream that knows how to optimally "chunk" the
>>> bytes into fixed-size packets.  On the receiving side these are fed into a
>>> similar input stream for deserialization.  The message only contains
>>> information about the operation it represents.
>>> 
>>> Why don't we do something similar for the new client/server protocol?
>>> 
>>> 
 Le 5/5/2017 à 7:28 AM, Jacob Barrett a écrit :
 
 On Thu, May 4, 2017 at 2:52 PM Hitesh Khamesra
 
 wrote:
 
 Basically, thread/layer should not hold any resources while serializing
> the object or chunk.  We should be able to see this flow (ms1-chunk1,
> msg2-chunk1, ms1-chunk2, msg3-chunk, msg2-chunk2, so on ...)
> 
> Correct, but putting that in the message layer is not appropriate. The
 simple solution is that the multiple channels can be achieved with
 multiple
 sockets. The later optimization is to add a channel multiplexer layer
 between the message and socket layers.
 
 If we put it in the message layer, not only does it for the message to
 tackle something it shouldn't be concerned with, reassembling itself, but
 it also forces all implementors to tackle this logic up front. By layering
 we can release without, implementors aren't forced into understanding the
 logic, and later we can release the layers and the client can negotiate.
 
 
 
 On other pdx note: to de-serialize the pdx we need length of serialized
> bytes, so that we can read field offset from serialized stream, and then
> can read field value. Though, I can imagine with the help of pdxType, we
> can interpret serialized stream.
> 
> Yes, so today PDX serialization would be no worse, the PDX serializer
 would
 have to buffer, but other may not have to. The length of the buffered PDX
 could be used as the first chunk length and complete in single chunk.
 Although, I suspect that amortized overhead of splitting the chunks  will
 be nil anyway.
 
 The point is that the message encoding of values should NOT have any
 unbounded length fields and require long or many buffers to complete
 serialization. By chunking you can accomplish this by not needing to
 buffer
 the whole stream, just small (say 1k), chunks at a time to get the chunk
 length.
 
 Buffers == Latency
 
 -Jake
 
 
>

[jira] [Commented] (GEODE-237) Remove EntryEvent deprecated methods


[ 
https://issues.apache.org/jira/browse/GEODE-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998706#comment-15998706
 ] 

ASF GitHub Bot commented on GEODE-237:
--

Github user dschneider-pivotal commented on the issue:

https://github.com/apache/geode/pull/464
  
This change looks good. I noticed travis CI failed with the following. But 
it looks like isExpiration was removed in some other commit so it is not clear 
to me why this one got the following failure.


:geode-core:compileTestJava/home/travis/build/apache/geode/geode-core/src/test/java/org/apache/geode/TXJUnitTest.java:3009:
 error: cannot find symbol
  assertTrue(!event.isExpiration());
   ^
  symbol:   method isExpiration()
  location: variable event of type EntryEvent


> Remove EntryEvent deprecated methods
> 
>
> Key: GEODE-237
> URL: https://issues.apache.org/jira/browse/GEODE-237
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The following EntryEvent methods need to be removed:
> - isLocalLoad: change to getOperation().isLocalLoad
> - isNetLoad: change to getOperation().isNetLoad
> - isLoad: change to getOperation().isLoad
> - isNetSearch: change to getOperation().isNetSearch
> - isBridgeEvent: change to hasClientOrigin
> these should be pretty easy to change



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #464: GEODE-237: Removed deprecated API from EntryEvent

2017-05-05 Thread dschneider-pivotal

Github user dschneider-pivotal commented on the issue:

https://github.com/apache/geode/pull/464
  
This change looks good. I noticed travis CI failed with the following. But 
it looks like isExpiration was removed in some other commit so it is not clear 
to me why this one got the following failure.


:geode-core:compileTestJava/home/travis/build/apache/geode/geode-core/src/test/java/org/apache/geode/TXJUnitTest.java:3009:
 error: cannot find symbol
  assertTrue(!event.isExpiration());
   ^
  symbol:   method isExpiration()
  location: variable event of type EntryEvent


---
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: [gemfire-dev] New Client-Server Protocol Proposal

Yes, of course it does but we don't serialize directly to a socket 
output stream because it's slow.  I agree that this could be left out 
and added later as an optimization.


Le 5/5/2017 à 10:33 AM, Galen M O'Sullivan a écrit :

I think TCP does exactly this for us.

On Fri, May 5, 2017 at 9:08 AM, Bruce Schuchardt 
wrote:


This is very similar to how peer-to-peer messaging is performed in Geode.
Messages are serialized to a stream that knows how to optimally "chunk" the
bytes into fixed-size packets.  On the receiving side these are fed into a
similar input stream for deserialization.  The message only contains
information about the operation it represents.

Why don't we do something similar for the new client/server protocol?


Le 5/5/2017 à 7:28 AM, Jacob Barrett a écrit :


On Thu, May 4, 2017 at 2:52 PM Hitesh Khamesra

wrote:

Basically, thread/layer should not hold any resources while serializing

the object or chunk.  We should be able to see this flow (ms1-chunk1,
msg2-chunk1, ms1-chunk2, msg3-chunk, msg2-chunk2, so on ...)

Correct, but putting that in the message layer is not appropriate. The

simple solution is that the multiple channels can be achieved with
multiple
sockets. The later optimization is to add a channel multiplexer layer
between the message and socket layers.

If we put it in the message layer, not only does it for the message to
tackle something it shouldn't be concerned with, reassembling itself, but
it also forces all implementors to tackle this logic up front. By layering
we can release without, implementors aren't forced into understanding the
logic, and later we can release the layers and the client can negotiate.



On other pdx note: to de-serialize the pdx we need length of serialized

bytes, so that we can read field offset from serialized stream, and then
can read field value. Though, I can imagine with the help of pdxType, we
can interpret serialized stream.

Yes, so today PDX serialization would be no worse, the PDX serializer

would
have to buffer, but other may not have to. The length of the buffered PDX
could be used as the first chunk length and complete in single chunk.
Although, I suspect that amortized overhead of splitting the chunks  will
be nil anyway.

The point is that the message encoding of values should NOT have any
unbounded length fields and require long or many buffers to complete
serialization. By chunking you can accomplish this by not needing to
buffer
the whole stream, just small (say 1k), chunks at a time to get the chunk
length.

Buffers == Latency

-Jake

[jira] [Resolved] (GEODE-1337) Define the API for lucene per-field analyzers

2017-05-05 Thread Barry Oglesby (JIRA)


 [ 
https://issues.apache.org/jira/browse/GEODE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Barry Oglesby resolved GEODE-1337.
--
Resolution: Not A Bug

> Define the API for lucene per-field analyzers
> -
>
> Key: GEODE-1337
> URL: https://issues.apache.org/jira/browse/GEODE-1337
> Project: Geode
>  Issue Type: Sub-task
>  Components: lucene
>Reporter: Barry Oglesby
>
> The current API (Map) is used by LuceneService:
> {noformat}
> public void createIndex(String indexName, String regionPath, Map Analyzer> analyzerPerField);
> {noformat}
> It is also used by LuceneIndex:
> {noformat}
> public Map getFieldAnalyzers();
> {noformat}
> Three options are:
> - keep it as it is
> - change it to {{Map}}
> - change it to {{Map}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [gemfire-dev] New Client-Server Protocol Proposal

2017-05-05 Thread Jacob Barrett

It does! 

Both fragmenting and multiple channels as multiple sockets. 

Sent from my iPhone

> On May 5, 2017, at 10:33 AM, Galen M O'Sullivan  wrote:
> 
> I think TCP does exactly this for us.
> 
> On Fri, May 5, 2017 at 9:08 AM, Bruce Schuchardt 
> wrote:
> 
>> This is very similar to how peer-to-peer messaging is performed in Geode.
>> Messages are serialized to a stream that knows how to optimally "chunk" the
>> bytes into fixed-size packets.  On the receiving side these are fed into a
>> similar input stream for deserialization.  The message only contains
>> information about the operation it represents.
>> 
>> Why don't we do something similar for the new client/server protocol?
>> 
>> 
>>> Le 5/5/2017 à 7:28 AM, Jacob Barrett a écrit :
>>> 
>>> On Thu, May 4, 2017 at 2:52 PM Hitesh Khamesra
>>> 
>>> wrote:
>>> 
>>> Basically, thread/layer should not hold any resources while serializing
 the object or chunk.  We should be able to see this flow (ms1-chunk1,
 msg2-chunk1, ms1-chunk2, msg3-chunk, msg2-chunk2, so on ...)
 
 Correct, but putting that in the message layer is not appropriate. The
>>> simple solution is that the multiple channels can be achieved with
>>> multiple
>>> sockets. The later optimization is to add a channel multiplexer layer
>>> between the message and socket layers.
>>> 
>>> If we put it in the message layer, not only does it for the message to
>>> tackle something it shouldn't be concerned with, reassembling itself, but
>>> it also forces all implementors to tackle this logic up front. By layering
>>> we can release without, implementors aren't forced into understanding the
>>> logic, and later we can release the layers and the client can negotiate.
>>> 
>>> 
>>> 
>>> On other pdx note: to de-serialize the pdx we need length of serialized
 bytes, so that we can read field offset from serialized stream, and then
 can read field value. Though, I can imagine with the help of pdxType, we
 can interpret serialized stream.
 
 Yes, so today PDX serialization would be no worse, the PDX serializer
>>> would
>>> have to buffer, but other may not have to. The length of the buffered PDX
>>> could be used as the first chunk length and complete in single chunk.
>>> Although, I suspect that amortized overhead of splitting the chunks  will
>>> be nil anyway.
>>> 
>>> The point is that the message encoding of values should NOT have any
>>> unbounded length fields and require long or many buffers to complete
>>> serialization. By chunking you can accomplish this by not needing to
>>> buffer
>>> the whole stream, just small (say 1k), chunks at a time to get the chunk
>>> length.
>>> 
>>> Buffers == Latency
>>> 
>>> -Jake
>>> 
>>> 
>>

Re: Remove keys from a PartitionedRegion

2017-05-05 Thread Barry Oglesby

Goutam,

What are you doing to get from the input id to the actual keys to delete?
Are you running a query? If so, how are you running it, and is it indexed?

Thanks,
Barry Oglesby


On Tue, May 2, 2017 at 11:02 AM, Goutam Tadi  wrote:

> Hi Barry,
>
> 1) OptimizeForWrite returns true.
>
> 2)
> FunctionService.onRegion(event.getRegion()).withArgs(id).execute(
> DeleteCollectedKeysFunction.ID);
> 
>
> idabove helps to retrieve the set of keys inside the DeleteCollectedKeys
>  funciton.
>
> Thanks.
>
>
>
>
>
> On Mon, May 1, 2017 at 5:17 PM Barry Oglesby  wrote:
>
> > Are you passing the keys as a filter or an argument? What does
> > optimizeForWrite in your function return?
> >
> > Thanks,
> > Barry Oglesby
> >
> >
> > On Mon, May 1, 2017 at 4:41 PM, Goutam Tadi  wrote:
> >
> > > Hi Dan,
> > >
> > > Thanks for the reply.
> > > No, we are neither executing the function nor passing keys from a
> client.
> > > We are trying to remove a significant portion of the keys from a region
> > > (most, but not all) at once.
> > >
> > > Thanks.
> > >
> > > On Mon, May 1, 2017 at 2:40 PM Dan Smith  wrote:
> > >
> > > > That seems like it should do things fairly quickly. Are you executing
> > the
> > > > function from a client? Did you find that using a function was
> actually
> > > > faster than just calling removeAll from the client? I think removeAll
> > > from
> > > > the client should send your keys in a single message, similar to your
> > > > function approach.
> > > >
> > > > How many keys are you trying to remove? If you have a really large
> > number
> > > > of keys, it might be better to batch up the keys. You could do
> multiple
> > > > removeAlls from the client, perhaps even in parallel.
> > > >
> > > > -Dan
> > > >
> > > > On Mon, May 1, 2017 at 12:19 PM, Goutam Tadi 
> wrote:
> > > >
> > > > > Hi Team,
> > > > >
> > > > > With +Bradford D Boyle 
> > > > >
> > > > > We are trying to remove a set of keys from a `PartitionedRegion`.
> > > > > Currently, we execute a function with `onRegion()`. Inside the
> > > function,
> > > > we
> > > > > call `PartitionRegionHelper.getLocalPrimaryData()` and use the
> > > returned
> > > > > region to execute `region.removeAll(keys)`.
> > > > >
> > > > > The problem we are facing is that is slow. Is there a faster way to
> > > > remove
> > > > > a set of keys from a partitioned region?
> > > > >
> > > > > We are considering using `getDataStore().
> getAllLocalBucketRegions()`
> > > to
> > > > > get
> > > > > the set of `BucketRegion`s and then using a thread pool to remove
> the
> > > > keys
> > > > > in parallel. Are there alternative approaches?
> > > > >
> > > > > Thanks,
> > > > > Goutam Tadi.
> > > > > --
> > > > > Regards,
> > > > > *Goutam Tadi.*
> > > > >
> > > >
> > > --
> > > Regards,
> > > *Goutam Tadi.*
> > >
> >
> --
> Regards,
> *Goutam Tadi.*
>

Re: [gemfire-dev] New Client-Server Protocol Proposal

2017-05-05 Thread Galen M O'Sullivan

I think TCP does exactly this for us.

On Fri, May 5, 2017 at 9:08 AM, Bruce Schuchardt 
wrote:

> This is very similar to how peer-to-peer messaging is performed in Geode.
> Messages are serialized to a stream that knows how to optimally "chunk" the
> bytes into fixed-size packets.  On the receiving side these are fed into a
> similar input stream for deserialization.  The message only contains
> information about the operation it represents.
>
> Why don't we do something similar for the new client/server protocol?
>
>
> Le 5/5/2017 à 7:28 AM, Jacob Barrett a écrit :
>
>> On Thu, May 4, 2017 at 2:52 PM Hitesh Khamesra
>> 
>> wrote:
>>
>> Basically, thread/layer should not hold any resources while serializing
>>> the object or chunk.  We should be able to see this flow (ms1-chunk1,
>>> msg2-chunk1, ms1-chunk2, msg3-chunk, msg2-chunk2, so on ...)
>>>
>>> Correct, but putting that in the message layer is not appropriate. The
>> simple solution is that the multiple channels can be achieved with
>> multiple
>> sockets. The later optimization is to add a channel multiplexer layer
>> between the message and socket layers.
>>
>> If we put it in the message layer, not only does it for the message to
>> tackle something it shouldn't be concerned with, reassembling itself, but
>> it also forces all implementors to tackle this logic up front. By layering
>> we can release without, implementors aren't forced into understanding the
>> logic, and later we can release the layers and the client can negotiate.
>>
>>
>>
>> On other pdx note: to de-serialize the pdx we need length of serialized
>>> bytes, so that we can read field offset from serialized stream, and then
>>> can read field value. Though, I can imagine with the help of pdxType, we
>>> can interpret serialized stream.
>>>
>>> Yes, so today PDX serialization would be no worse, the PDX serializer
>> would
>> have to buffer, but other may not have to. The length of the buffered PDX
>> could be used as the first chunk length and complete in single chunk.
>> Although, I suspect that amortized overhead of splitting the chunks  will
>> be nil anyway.
>>
>> The point is that the message encoding of values should NOT have any
>> unbounded length fields and require long or many buffers to complete
>> serialization. By chunking you can accomplish this by not needing to
>> buffer
>> the whole stream, just small (say 1k), chunks at a time to get the chunk
>> length.
>>
>> Buffers == Latency
>>
>> -Jake
>>
>>
>

Re: Review Request 58888: GEODE-2632: change dependencies on GemFireCacheImpl to InternalCache


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


Ship it!




I have now finished reviewing the changes to to product code. No new comments 
or issues on this batch of diffs.

- Ken Howe


On May 3, 2017, 10:10 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 3, 2017, 10:10 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Jinmei Liao, Jared Stewart, Ken 
> Howe, and Patrick Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2632: change dependencies on GemFireCacheImpl to InternalCache
> 
> * misc cleanup of code where possible
> 
> I'm running full regression and precheckin. Sorry this is so many files -- 
> I'm not sure this is even practical to review :/
> 
> I'd like to avoid any further cleanup and just get this committed asap to 
> avoid conflicts. Let's hold off on throwing more changes on top of this if 
> you see more lines of code in a file that you'd like cleaned up. I obviously 
> want to fix problems in any code that I touched though!
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/jca/java/org/apache/geode/internal/ra/spi/JCALocalTransaction.java
>  112f2fa44478f00782bcb717d8cb75233c979dce 
>   
> geode-core/src/jca/java/org/apache/geode/internal/ra/spi/JCAManagedConnection.java
>  520f7e245ca3493d54ac661da29f58a3dfc71189 
>   geode-core/src/main/java/org/apache/geode/DataSerializer.java 
> 58518f4f5d43b3fe214a1218703360928efdee52 
>   geode-core/src/main/java/org/apache/geode/admin/GemFireMemberStatus.java 
> 5b4e59ef341007a4e42cd5a10b4e8a2eb4d18deb 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/CacheHealthEvaluator.java
>  f7ff9ede1e074425ce7aa7bed1a63c72c5174bf6 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/FinishBackupRequest.java
>  25abd7ee5d346d764d68339ae6c03b2cffc63bc8 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/FlushToDiskRequest.java
>  ff6dd9d2088124203842a06d3a794e00a5636246 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/MemberHealthEvaluator.java
>  951b364718f43c5efc85c0f0f0e5d54e24d87ced 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/PrepareBackupRequest.java
>  7025721180cb6b158cff4b21bfcea6549780ccd3 
>   geode-core/src/main/java/org/apache/geode/cache/AttributesFactory.java 
> 1a46f241a7b3a4bbbd47da70c227b3e3ea237fd0 
>   geode-core/src/main/java/org/apache/geode/cache/CacheClosedException.java 
> b24bc2fc5ad39737e908f9df2704b62728222629 
>   geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
> 0772dcf86b3d3ea9eebfe1d324c8fa043fa8ac79 
>   geode-core/src/main/java/org/apache/geode/cache/DynamicRegionFactory.java 
> 57a1a465c1bd0d91d8bb83ad2b97db1f2efbb025 
>   geode-core/src/main/java/org/apache/geode/cache/GemFireCache.java 
> e60bc59a88051ac11a863ea10be3e2bf07e4cbe7 
>   geode-core/src/main/java/org/apache/geode/cache/Region.java 
> 3eef5438e78a94acd669764e88daaafe6f5fa388 
>   geode-core/src/main/java/org/apache/geode/cache/RegionFactory.java 
> 3a2e9f68c96f9e4aae5a837e175014a3598f69ea 
>   
> geode-core/src/main/java/org/apache/geode/cache/TransactionDataRebalancedException.java
>  fded49f3c00772f38bac14bc57fa4614144930c1 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/AsyncEventQueueFactoryImpl.java
>  1a4052b27688c8e04addf6987ce39ea006f71cc5 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/AsyncEventQueueImpl.java
>  0def5d283e359b1766fc90dfa05903526c672b0b 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/ParallelAsyncEventQueueImpl.java
>  e799880d715ed1fba65df305cf37e92f27db54ea 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/SerialAsyncEventQueueImpl.java
>  9252dc745b848ea7a5aa8793a1fdb3a3c004c7ee 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/ClientCacheFactory.java
>  e72cbff048b5a7ecb24594382d776feaa8e0f4bd 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ClientRegionFactoryImpl.java
>  ef676673046c32f68558f85516c674f7dcc6e982 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ConnectionImpl.java
>  a494138316d8538f3aebeffb7075bb2db33b6532 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecutablePool.java
>  54521d52879088eeceea15a44933c909d536b76f 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecuteFunctionOp.java
>  d32e0f41bd7a939241227137e2218eef72ccfc56 
>   
>

[jira] [Assigned] (GEODE-2881) waitForFlushBeforeExecuteTextSearch instance hits cache closed exception because test is completed

2017-05-05 Thread nabarun (JIRA)


 [ 
https://issues.apache.org/jira/browse/GEODE-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

nabarun reassigned GEODE-2881:
--

Assignee: nabarun

> waitForFlushBeforeExecuteTextSearch instance hits cache closed exception 
> because test is completed
> --
>
> Key: GEODE-2881
> URL: https://issues.apache.org/jira/browse/GEODE-2881
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
>
> Issue:
> The returnCorrectResultsWhenIndexUpdateHappensIntheMiddleofGII tests creates 
> a test hook which calls waitForFlushBeforeExecuteTextSearch when GII is 
> requested and also the test calls waitForFlushBeforeExecuteTextSearch before 
> executing a Lucene Query. 
> Both calls occur in different threads and if the wait for flush called by the 
> test hook is still executing while the test is completed, the caches are shut 
> down and it gets a CacheClosedException
> Solution:
> Make sure the test hook's wait for flush is completed before the test is 
> terminated / before executing a query



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2881) waitForFlushBeforeExecuteTextSearch instance hits cache closed exception because test is completed

2017-05-05 Thread nabarun (JIRA)

nabarun created GEODE-2881:
--

 Summary: waitForFlushBeforeExecuteTextSearch instance hits cache 
closed exception because test is completed
 Key: GEODE-2881
 URL: https://issues.apache.org/jira/browse/GEODE-2881
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: nabarun


Issue:
The returnCorrectResultsWhenIndexUpdateHappensIntheMiddleofGII tests creates a 
test hook which calls waitForFlushBeforeExecuteTextSearch when GII is requested 
and also the test calls waitForFlushBeforeExecuteTextSearch before executing a 
Lucene Query. 
Both calls occur in different threads and if the wait for flush called by the 
test hook is still executing while the test is completed, the caches are shut 
down and it gets a CacheClosedException

Solution:
Make sure the test hook's wait for flush is completed before the test is 
terminated / before executing a query



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2880) value auto complete for member and file names does not work

2017-05-05 Thread Jinmei Liao (JIRA)

Jinmei Liao created GEODE-2880:
--

 Summary: value auto complete for member and file names does not 
work
 Key: GEODE-2880
 URL: https://issues.apache.org/jira/browse/GEODE-2880
 Project: Geode
  Issue Type: Bug
Reporter: Jinmei Liao
 Fix For: 1.2.0


those command should be auto-completed with the correct values:
connect --locator=yy
stop server --member=xx
start server --property-file=filename



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 58937: GEODE-2865 data loss in initial-image replication with multicas


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




geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/JGroupsMessenger.java
Lines 49 (patched)


I'll remove this import statement.


- Bruce Schuchardt


On May 5, 2017, 4:57 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58937/
> ---
> 
> (Updated May 5, 2017, 4:57 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-2865
> https://issues.apache.org/jira/browse/GEODE-2865
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The state-flush algorithm relies on MembershipManager.waitForMessageState() 
> to ensure that all operations have been received and applied to the cache 
> prior to state replication starting.  For multicast there was a flaw in the 
> algorithm caused by two things: 1) cache operations were being sent 
> out-of-band, allowing them to be processed out of order with the state-flush 
> message, and 2) JGroupsMessenger was only waiting for the messages to be 
> dispatched by NAKACK2, which isn't necessarily the same as being dispatched 
> to the DistributionManager Executor that processes the message.
> 
> Cache operation messages are now sent in-band.
> JGroupsMessenger now tracks NAKACK2 (multicast) sequence numbers of messages 
> dispatched to the DistributionManager and this is used in 
> waitForMessageState() to make sure the messages have been queued.
> If multicast is enabled we now flush the serial executor to in 
> waitForMessageState() to make sure that all messages queued in it have been 
> applied to the region.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/JGroupsMessenger.java
>  e99eff2be344d54da67c257a0bfa73ad8268c4c6 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
>  8ae66d0b6839cfbd46b479d896104f54fd11a68d 
>   
> geode-core/src/test/java/org/apache/geode/distributed/DistributedSystemDUnitTest.java
>  9a64f531431e714916765d6d6c741841ef719fb8 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/messenger/JGroupsMessengerJUnitTest.java
>  307b5948c02befee61d61b628c38b8b8b8693c4d 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/FixedPRSinglehopDUnitTest.java
>  7e798c8358aaec070d3dd9d04c2486bd33a21d9e 
> 
> 
> Diff: https://reviews.apache.org/r/58937/diff/2/
> 
> 
> Testing
> ---
> 
> passes precheckin and modified unit tests
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 58937: GEODE-2865 data loss in initial-image replication with multicas


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

(Updated May 5, 2017, 4:57 p.m.)


Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo Kohlmeyer.


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


Repository: geode


Description
---

The state-flush algorithm relies on MembershipManager.waitForMessageState() to 
ensure that all operations have been received and applied to the cache prior to 
state replication starting.  For multicast there was a flaw in the algorithm 
caused by two things: 1) cache operations were being sent out-of-band, allowing 
them to be processed out of order with the state-flush message, and 2) 
JGroupsMessenger was only waiting for the messages to be dispatched by NAKACK2, 
which isn't necessarily the same as being dispatched to the DistributionManager 
Executor that processes the message.

Cache operation messages are now sent in-band.
JGroupsMessenger now tracks NAKACK2 (multicast) sequence numbers of messages 
dispatched to the DistributionManager and this is used in waitForMessageState() 
to make sure the messages have been queued.
If multicast is enabled we now flush the serial executor to in 
waitForMessageState() to make sure that all messages queued in it have been 
applied to the region.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/JGroupsMessenger.java
 e99eff2be344d54da67c257a0bfa73ad8268c4c6 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
 8ae66d0b6839cfbd46b479d896104f54fd11a68d 
  
geode-core/src/test/java/org/apache/geode/distributed/DistributedSystemDUnitTest.java
 9a64f531431e714916765d6d6c741841ef719fb8 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/messenger/JGroupsMessengerJUnitTest.java
 307b5948c02befee61d61b628c38b8b8b8693c4d 
  
geode-core/src/test/java/org/apache/geode/internal/cache/FixedPRSinglehopDUnitTest.java
 7e798c8358aaec070d3dd9d04c2486bd33a21d9e 


Diff: https://reviews.apache.org/r/58937/diff/2/

Changes: https://reviews.apache.org/r/58937/diff/1-2/


Testing
---

passes precheckin and modified unit tests


Thanks,

Bruce Schuchardt

Re: [gemfire-dev] New Client-Server Protocol Proposal

2017-05-05 Thread Jacob Barrett

I would leave it for a later optimization.

Sent from my iPhone

> On May 5, 2017, at 9:08 AM, Bruce Schuchardt  wrote:
> 
> This is very similar to how peer-to-peer messaging is performed in Geode.  
> Messages are serialized to a stream that knows how to optimally "chunk" the 
> bytes into fixed-size packets.  On the receiving side these are fed into a 
> similar input stream for deserialization.  The message only contains 
> information about the operation it represents.
> 
> Why don't we do something similar for the new client/server protocol?
> 
>> Le 5/5/2017 à 7:28 AM, Jacob Barrett a écrit :
>> On Thu, May 4, 2017 at 2:52 PM Hitesh Khamesra 
>> wrote:
>> 
>>> Basically, thread/layer should not hold any resources while serializing
>>> the object or chunk.  We should be able to see this flow (ms1-chunk1,
>>> msg2-chunk1, ms1-chunk2, msg3-chunk, msg2-chunk2, so on ...)
>>> 
>> Correct, but putting that in the message layer is not appropriate. The
>> simple solution is that the multiple channels can be achieved with multiple
>> sockets. The later optimization is to add a channel multiplexer layer
>> between the message and socket layers.
>> 
>> If we put it in the message layer, not only does it for the message to
>> tackle something it shouldn't be concerned with, reassembling itself, but
>> it also forces all implementors to tackle this logic up front. By layering
>> we can release without, implementors aren't forced into understanding the
>> logic, and later we can release the layers and the client can negotiate.
>> 
>> 
>> 
>>> On other pdx note: to de-serialize the pdx we need length of serialized
>>> bytes, so that we can read field offset from serialized stream, and then
>>> can read field value. Though, I can imagine with the help of pdxType, we
>>> can interpret serialized stream.
>>> 
>> Yes, so today PDX serialization would be no worse, the PDX serializer would
>> have to buffer, but other may not have to. The length of the buffered PDX
>> could be used as the first chunk length and complete in single chunk.
>> Although, I suspect that amortized overhead of splitting the chunks  will
>> be nil anyway.
>> 
>> The point is that the message encoding of values should NOT have any
>> unbounded length fields and require long or many buffers to complete
>> serialization. By chunking you can accomplish this by not needing to buffer
>> the whole stream, just small (say 1k), chunks at a time to get the chunk
>> length.
>> 
>> Buffers == Latency
>> 
>> -Jake
>> 
>

Re: [gemfire-dev] New Client-Server Protocol Proposal

This is very similar to how peer-to-peer messaging is performed in 
Geode.  Messages are serialized to a stream that knows how to optimally 
"chunk" the bytes into fixed-size packets.  On the receiving side these 
are fed into a similar input stream for deserialization.  The message 
only contains information about the operation it represents.


Why don't we do something similar for the new client/server protocol?

Le 5/5/2017 à 7:28 AM, Jacob Barrett a écrit :

On Thu, May 4, 2017 at 2:52 PM Hitesh Khamesra 
wrote:


Basically, thread/layer should not hold any resources while serializing
the object or chunk.  We should be able to see this flow (ms1-chunk1,
msg2-chunk1, ms1-chunk2, msg3-chunk, msg2-chunk2, so on ...)


Correct, but putting that in the message layer is not appropriate. The
simple solution is that the multiple channels can be achieved with multiple
sockets. The later optimization is to add a channel multiplexer layer
between the message and socket layers.

If we put it in the message layer, not only does it for the message to
tackle something it shouldn't be concerned with, reassembling itself, but
it also forces all implementors to tackle this logic up front. By layering
we can release without, implementors aren't forced into understanding the
logic, and later we can release the layers and the client can negotiate.




On other pdx note: to de-serialize the pdx we need length of serialized
bytes, so that we can read field offset from serialized stream, and then
can read field value. Though, I can imagine with the help of pdxType, we
can interpret serialized stream.


Yes, so today PDX serialization would be no worse, the PDX serializer would
have to buffer, but other may not have to. The length of the buffered PDX
could be used as the first chunk length and complete in single chunk.
Although, I suspect that amortized overhead of splitting the chunks  will
be nil anyway.

The point is that the message encoding of values should NOT have any
unbounded length fields and require long or many buffers to complete
serialization. By chunking you can accomplish this by not needing to buffer
the whole stream, just small (say 1k), chunks at a time to get the chunk
length.

Buffers == Latency

-Jake

Re: Review Request 58813: GEODE-2776 After region is updated with loader, the ClientEvent is set with current entry version tag

2017-05-05 Thread Darrel Schneider


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


Ship it!




Ship It!

- Darrel Schneider


On May 4, 2017, 8:57 p.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58813/
> ---
> 
> (Updated May 4, 2017, 8:57 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Eric Shu, and Lynn Gallinat.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> When client does a get() which results in adding an entry by calling loader 
> on server side, the client event returned back is not updated with the 
> version tag that is created with the new entry on server. This results in 
> client having a different version tag than the server side entry. If client 
> has registered event, and is concurrently updating the entry (from get() call 
> and an register-event from server), it could result in data consistency 
> between client and server.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java
>  0c967c9 
>   geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
> 2dec53b 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/DistributedRegionSearchLoadJUnitTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/58813/diff/5/
> 
> 
> Testing
> ---
> 
> Manual testing.
> Running new unit test (added) with and without changes.
> precheckin in progress.
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

[jira] [Closed] (GEODE-2807) Replace SharedPtr with std::shared_ptr


 [ 
https://issues.apache.org/jira/browse/GEODE-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacob S. Barrett closed GEODE-2807.
---

> Replace SharedPtr with std::shared_ptr
> --
>
> Key: GEODE-2807
> URL: https://issues.apache.org/jira/browse/GEODE-2807
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Replace proprietary SharePtr with C++11 std::shared_ptr.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2807) Replace SharedPtr with std::shared_ptr


 [ 
https://issues.apache.org/jira/browse/GEODE-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacob S. Barrett resolved GEODE-2807.
-
Resolution: Duplicate

> Replace SharedPtr with std::shared_ptr
> --
>
> Key: GEODE-2807
> URL: https://issues.apache.org/jira/browse/GEODE-2807
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Replace proprietary SharePtr with C++11 std::shared_ptr.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2741) Use C++11 shared pointer over custom shared pointer


[ 
https://issues.apache.org/jira/browse/GEODE-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998499#comment-15998499
 ] 

Jacob S. Barrett commented on GEODE-2741:
-

Docs Changes
* All references to {{SharedPtr}} need to be replaced with 
[{{std::shared_ptr}}|http://en.cppreference.com/w/cpp/memory/shared_ptr] 
(suggest using this link too)
* All {{\*Ptr}} typedefs replaced with explicit {{std::shared_ptr<\*>}}. For 
example, {{CacheableStringPtr}} is now {{std::shared_ptr}}. 
(not complete)


> Use C++11 shared pointer over custom shared pointer
> ---
>
> Key: GEODE-2741
> URL: https://issues.apache.org/jira/browse/GEODE-2741
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Addison
>Assignee: Jacob S. Barrett
>
> *Context*
> Now that the Native Client is compatible with C++11, we can use its shared 
> pointer over the custom shared pointer we use today.
> *Definition of Done*
> The custom shared pointer is nowhere to be found in the codebase



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2741) Use C++11 shared pointer over custom shared pointer


 [ 
https://issues.apache.org/jira/browse/GEODE-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacob S. Barrett reassigned GEODE-2741:
---

Assignee: Jacob S. Barrett

> Use C++11 shared pointer over custom shared pointer
> ---
>
> Key: GEODE-2741
> URL: https://issues.apache.org/jira/browse/GEODE-2741
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Addison
>Assignee: Jacob S. Barrett
>
> *Context*
> Now that the Native Client is compatible with C++11, we can use its shared 
> pointer over the custom shared pointer we use today.
> *Definition of Done*
> The custom shared pointer is nowhere to be found in the codebase



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Review Request 59027: GEODE-1996 Confusing references to "multicast" for locators ports

2017-05-05 Thread Dave Barnes


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

Review request for geode, Joey McAllister and Udo Kohlmeyer.


Repository: geode


Description
---

GEODE-1996 Confusing references to "multicast" for locators ports


Diffs
-

  
geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb
 a06a8c81cd12260f7384a202a4a0d5643806a367 
  geode-docs/configuring/running/firewalls_ports.html.md.erb 
11e4554887cbc845b881ad61959d2a4345bb0c8a 
  
geode-docs/managing/monitor_tune/multicast_communication_runtime_considerations.html.md.erb
 77fd42b9c043b613c8dcf68feda0bd49d482cd1a 
  
geode-docs/managing/monitor_tune/socket_communication_ephemeral_tcp_port_limits.html.md.erb
 3df570a3859f1b49874f682b9639e642584666c2 
  
geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb
 a075e08533e74ae986db9efde552c392cd5cce2c 
  
geode-docs/managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html.md.erb
 41884a2ecc21f607a91eb8910b001be77aa1ad6a 
  
geode-docs/managing/monitor_tune/socket_communication_tcpip_p2p_handshake_timeouts.html.md.erb
 486c337092382f9bde702e677ba1122583cff440 
  geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb 
ca20bf81dbccaad1beaa52b064db1e1644de86e6 
  geode-docs/managing/monitor_tune/udp_communication.html.md.erb 
4a5d3c0bf8f24275a4040e8f0f1926a06e990b7f 
  geode-docs/reference/statistics/statistics_list.html.md.erb 
7f7b76f79e944ffc495f8974712b1c53b9863a55 
  geode-docs/tools_modules/gfsh/command-pages/connect.html.md.erb 
c83d2ffe92c7784b5f41b63e879a3199a26ee88a 


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


Testing
---

Corrected two references to the locator's "multicast port" as described in the 
JIRA ticket. Searched the entire user guide, found no other occurrences. In the 
process, corrected some typos and formatting issues, which are included in this 
checkin to save the overhead of creating a separate ticket and review cycle.


Thanks,

Dave Barnes

[jira] [Commented] (GEODE-2832) Fixing the link of README.md


[ 
https://issues.apache.org/jira/browse/GEODE-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998473#comment-15998473
 ] 

ASF GitHub Bot commented on GEODE-2832:
---

Github user pivotal-jbarrett commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/95#discussion_r115026056
  
--- Diff: README.md ---
@@ -24,3 +24,33 @@ Native Client applications can be written in these 
client technologies:
 
 * [C++](https://isocpp.org)
 * [C#](https://msdn.microsoft.com/en-us/library/ms228593.aspx)
+
+## Export Control
+
+This distribution includes cryptographic software.
+The country in which you currently reside may have restrictions
+on the import, possession, use, and/or re-export to another country,
+of encryption software. BEFORE using any encryption software,
+please check your country's laws, regulations and policies
+concerning the import, possession, or use, and re-export of
+encryption software, to see if this is permitted.
+See  for more information.
+
+The U.S. Government Department of Commerce, Bureau of Industry and 
Security (BIS),
+has classified this software as Export Commodity Control Number (ECCN) 
5D002.C.1,
+which includes information security software using or performing
+cryptographic functions with asymmetric algorithms.
+The form and manner of this Apache Software Foundation distribution makes
+it eligible for export under the License Exception
+ENC Technology Software Unrestricted (TSU) exception
+(see the BIS Export Administration Regulations, Section 740.13)
+for both object code and source code.
+
+The following provides more details on the included cryptographic software:
+
+* Apache Geode is designed to be used with
+  [Java Secure Socket 
Extension](https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html)
 (JSSE) and
--- End diff --

Oh, I see, you merged rather rather than rebased. I think rather than going 
through all the paperwork I would just correct it inline with this issue. 
Either way is fine.


> Fixing the link of README.md
> 
>
> Key: GEODE-2832
> URL: https://issues.apache.org/jira/browse/GEODE-2832
> Project: Geode
>  Issue Type: Bug
>  Components: docs, native client
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> Fixed an error in Markdown link notation of README.md.
> - Delete the space between the display name and the destination URL.
> - Fixed link destination of native-client-intro.html
> - Fixed link of BUILDING.md



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #95: GEODE-2832: Fixing the link of README.md

2017-05-05 Thread pivotal-jbarrett

Github user pivotal-jbarrett commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/95#discussion_r115026056
  
--- Diff: README.md ---
@@ -24,3 +24,33 @@ Native Client applications can be written in these 
client technologies:
 
 * [C++](https://isocpp.org)
 * [C#](https://msdn.microsoft.com/en-us/library/ms228593.aspx)
+
+## Export Control
+
+This distribution includes cryptographic software.
+The country in which you currently reside may have restrictions
+on the import, possession, use, and/or re-export to another country,
+of encryption software. BEFORE using any encryption software,
+please check your country's laws, regulations and policies
+concerning the import, possession, or use, and re-export of
+encryption software, to see if this is permitted.
+See  for more information.
+
+The U.S. Government Department of Commerce, Bureau of Industry and 
Security (BIS),
+has classified this software as Export Commodity Control Number (ECCN) 
5D002.C.1,
+which includes information security software using or performing
+cryptographic functions with asymmetric algorithms.
+The form and manner of this Apache Software Foundation distribution makes
+it eligible for export under the License Exception
+ENC Technology Software Unrestricted (TSU) exception
+(see the BIS Export Administration Regulations, Section 740.13)
+for both object code and source code.
+
+The following provides more details on the included cryptographic software:
+
+* Apache Geode is designed to be used with
+  [Java Secure Socket 
Extension](https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html)
 (JSSE) and
--- End diff --

Oh, I see, you merged rather rather than rebased. I think rather than going 
through all the paperwork I would just correct it inline with this issue. 
Either way is fine.


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

[jira] [Commented] (GEODE-2832) Fixing the link of README.md