[jira] [Resolved] (GEODE-2828) AEQ needs to be created before the user region

[nabarun (JIRA)]

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

nabarun resolved GEODE-2828.

   Resolution: Fixed
Fix Version/s: 1.2.0

> AEQ needs to be created before the user region
> --
>
> Key: GEODE-2828
> URL: https://issues.apache.org/jira/browse/GEODE-2828
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
> Fix For: 1.2.0
>
>
> Issue:
> Events are lost as the region is being created, because the AEQ gets created 
> after the user region is created, and the indexes are not being created via 
> AEQ.
> Solution:
> 1. AEQ being created before the user region.
> 2. Processing of lucene events are being halted by a countdown latch and 
> starts processing after the user region is created.



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

[GitHub] geode pull request #481: GEODE-2828: AEQ being created before the user regio...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2828) AEQ needs to be created before the user region

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> AEQ needs to be created before the user region
> --
>
> Key: GEODE-2828
> URL: https://issues.apache.org/jira/browse/GEODE-2828
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>
> Issue:
> Events are lost as the region is being created, because the AEQ gets created 
> after the user region is created, and the indexes are not being created via 
> AEQ.
> Solution:
> 1. AEQ being created before the user region.
> 2. Processing of lucene events are being halted by a countdown latch and 
> starts processing after the user region is created.



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

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

[Jacob Barrett]

I agree completely with Dan. There is no reason to have flags for value 
encoding type in the message. I would argue that should be part of the value 
serialization layer. If something was placed in the message layer it should be 
more generic and allow for an unrestricted set of encodings by some ID.

Object {
variant ID codec;
byte[] payload;
}


-Jake


Sent from my iPhone

> On May 2, 2017, at 1:42 PM, Dan Smith  wrote:
> 
> I guess the value of building other messages on top of the function service
> mostly comes into play when we start talking about smarter clients that can
> do single hop. At that point it's really nice to have have a layer that
> lets us send a message to a single primary, or all of the members that host
> a region etc. It is also nice that right now if I add new function that
> functionality becomes available to gfsh, REST, Java, and C++ developers
> automatically.
> 
> I do agree that the new protocol could build in these concepts, and doesn't
> necessarily have to use function execution to achieve the same results. But
> do at least consider whether new developers will want to add new
> functionality to the server via functions or via your this new protocol. If
> it's harder to use the new protocol than to write a new function and invoke
> it from the client, then I think we've done something wrong.
> 
> 
> A couple of other comments, now that I've looked a little more:
> 
> 1) The list of error codes
> 
> seems really incomplete. It looks like we've picked a few of the possible
> exceptions geode could throw and assigned them integer ids? What is the
> rational for the exceptions that are included here vs. other exceptions?
> Also, not all messages would need to return these error codes.
> 
> 2) The existing protocol has some functionality even for basic puts that is
> not represented here. Client generate an event id that is associated with
> the put and send that to the server. These event ids are used to guarantee
> that if a client does put (A, 0) followed by put (A, 1), the resulting
> value will always be 1, even if the client timed out and retried put (A,
> 0). The event id prevents the lingered put that timed out on the server
> from affecting the state. I'm not saying the new protocol has to support
> this sort of behavior, but you might want to consider whether the current
> protocol should specify anything about how events are retried.
> 
> -Dan

[jira] [Assigned] (GEODE-254) Remove deprecated Region.keys and Region.entries

[Avinash Dongre (JIRA)]

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

Avinash Dongre reassigned GEODE-254:


Assignee: Avinash Dongre

> Remove deprecated Region.keys and Region.entries
> 
>
> Key: GEODE-254
> URL: https://issues.apache.org/jira/browse/GEODE-254
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Region.keys and Region.entries. Any calls can be simply 
> changed to Region.keySet and Region.entrySet so this should be an easy change.
> A large number of tests call the deprecated methods.



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

[jira] [Commented] (GEODE-254) Remove deprecated Region.keys and Region.entries

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-254:
--

GitHub user davinash opened a pull request:

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

GEODE-254: Removed deprecated Region.keys and Region.entries



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

$ git pull https://github.com/davinash/geode feature/GEODE-254

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

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


commit 2e2684dcf471f294a0d9da94bdba1c767436abe4
Author: adongre 
Date:   2017-05-02T09:11:55Z

GEODE-254: Removed deprecated Region.keys and Region.entries




> Remove deprecated Region.keys and Region.entries
> 
>
> Key: GEODE-254
> URL: https://issues.apache.org/jira/browse/GEODE-254
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Region.keys and Region.entries. Any calls can be simply 
> changed to Region.keySet and Region.entrySet so this should be an easy change.
> A large number of tests call the deprecated methods.



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

[GitHub] geode pull request #488: GEODE-254: Removed deprecated Region.keys and Regio...

[davinash]

GitHub user davinash opened a pull request:

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

GEODE-254: Removed deprecated Region.keys and Region.entries



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

$ git pull https://github.com/davinash/geode feature/GEODE-254

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

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


commit 2e2684dcf471f294a0d9da94bdba1c767436abe4
Author: adongre 
Date:   2017-05-02T09:11:55Z

GEODE-254: Removed deprecated Region.keys and Region.entries




---
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 58813: GEODE-2776 After region is updated with loader, the ClientEvent is set with current entry version tag

[anilkumar gingade]

> On April 28, 2017, 11:33 p.m., Darrel Schneider wrote:
> > geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java
> > Lines 2358 (patched)
> > 
> >
> > I just thought of one more possible issue.
> > I think you want to get the versionTag and the value from "re" 
> > atomically.
> > I remember a fix like this before in which you need to make sure the 
> > value you get from a region entry is the same as the version tag.

Good catch...Added this new changes posted.


- anilkumar


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


On April 28, 2017, 11:23 p.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58813/
> ---
> 
> (Updated April 28, 2017, 11:23 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
>  8cdc517 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/DistributedRegionSearchLoadJUnitTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/58813/diff/2/
> 
> 
> Testing
> ---
> 
> Manual testing.
> Running new unit test (added) with and without changes.
> precheckin in progress.
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

[jira] [Assigned] (GEODE-1325) Convert Tomcat{6,7}SessionsJUnitTest to IntegrationTest category

[Dan Smith (JIRA)]

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

Dan Smith reassigned GEODE-1325:


Assignee: Dan Smith

> Convert Tomcat{6,7}SessionsJUnitTest to IntegrationTest category
> 
>
> Key: GEODE-1325
> URL: https://issues.apache.org/jira/browse/GEODE-1325
> Project: Geode
>  Issue Type: Sub-task
>  Components: http session, tests
>Reporter: Jens Deppe
>Assignee: Dan Smith
> Fix For: 1.2.0
>
>




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

[jira] [Resolved] (GEODE-2830) Required permission for executing a function should be DATA:WRITE

[Dave Barnes (JIRA)]

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

Dave Barnes resolved GEODE-2830.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Required permission for executing a function should be DATA:WRITE
> -
>
> Key: GEODE-2830
> URL: https://issues.apache.org/jira/browse/GEODE-2830
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Diane Hardman
>Assignee: Dave Barnes
> Fix For: 1.2.0
>
>
> The required permission for executing a function as listed in the gfsh 
> command table (2nd table) is wrong in the docs:
> http://gemfire.docs.pivotal.io/geode/managing/security/implementing_authorization.html
> It is listed as DATA:MANAGE in the gfsh command table, but should be 
> DATA:WRITE.
> The correct permission is listed in the client operation table above the gfsh 
> table.



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

[jira] [Resolved] (GEODE-2843) User Guide - example should specify

[Dave Barnes (JIRA)]

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

Dave Barnes resolved GEODE-2843.

   Resolution: Fixed
Fix Version/s: 1.2.0

Fixed several occurrences on the client-cache reference page.

> User Guide - example should specify 
> --
>
> Key: GEODE-2843
> URL: https://issues.apache.org/jira/browse/GEODE-2843
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
> Fix For: 1.2.0
>
>
> Excerpt from John Blum's response to a user's question:
> See the example here: 
> http://geode.apache.org/docs/guide/11/reference/topics/client-cache.html#cc-pdx
> Unfortunately, the example is WRONG, as it is using the "peer" cache element 
> tag ( instead of ), but this reference ([5]) is from 
> client-cache section...



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

[jira] [Commented] (GEODE-2843) User Guide - example should specify

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2843:


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

Merge branch 'feature/GEODE-2843' into develop

* feature/GEODE-2843:
  GEODE-2843 User Guide - example should specify 


> User Guide - example should specify 
> --
>
> Key: GEODE-2843
> URL: https://issues.apache.org/jira/browse/GEODE-2843
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Excerpt from John Blum's response to a user's question:
> See the example here: 
> http://geode.apache.org/docs/guide/11/reference/topics/client-cache.html#cc-pdx
> Unfortunately, the example is WRONG, as it is using the "peer" cache element 
> tag ( instead of ), but this reference ([5]) is from 
> client-cache section...



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

[jira] [Commented] (GEODE-2843) User Guide - example should specify

[ASF GitHub Bot (JIRA)]

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

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

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/485
  
Merged


> User Guide - example should specify 
> --
>
> Key: GEODE-2843
> URL: https://issues.apache.org/jira/browse/GEODE-2843
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Excerpt from John Blum's response to a user's question:
> See the example here: 
> http://geode.apache.org/docs/guide/11/reference/topics/client-cache.html#cc-pdx
> Unfortunately, the example is WRONG, as it is using the "peer" cache element 
> tag ( instead of ), but this reference ([5]) is from 
> client-cache section...



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

[jira] [Commented] (GEODE-2843) User Guide - example should specify

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2843:


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

Merge branch 'feature/GEODE-2843' into develop

* feature/GEODE-2843:
  GEODE-2843 User Guide - example should specify 


> User Guide - example should specify 
> --
>
> Key: GEODE-2843
> URL: https://issues.apache.org/jira/browse/GEODE-2843
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Excerpt from John Blum's response to a user's question:
> See the example here: 
> http://geode.apache.org/docs/guide/11/reference/topics/client-cache.html#cc-pdx
> Unfortunately, the example is WRONG, as it is using the "peer" cache element 
> tag ( instead of ), but this reference ([5]) is from 
> client-cache section...



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

[jira] [Commented] (GEODE-2843) User Guide - example should specify

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2843:


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

Merge branch 'feature/GEODE-2843' into develop

* feature/GEODE-2843:
  GEODE-2843 User Guide - example should specify 


> User Guide - example should specify 
> --
>
> Key: GEODE-2843
> URL: https://issues.apache.org/jira/browse/GEODE-2843
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Excerpt from John Blum's response to a user's question:
> See the example here: 
> http://geode.apache.org/docs/guide/11/reference/topics/client-cache.html#cc-pdx
> Unfortunately, the example is WRONG, as it is using the "peer" cache element 
> tag ( instead of ), but this reference ([5]) is from 
> client-cache section...



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

[GitHub] geode issue #485: GEODE-2843 User Guide - example should specify

[davebarnes97]

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/485
  
Merged


---
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-2843) User Guide - example should specify

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2843:


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

GEODE-2843 User Guide - example should specify 


> User Guide - example should specify 
> --
>
> Key: GEODE-2843
> URL: https://issues.apache.org/jira/browse/GEODE-2843
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Excerpt from John Blum's response to a user's question:
> See the example here: 
> http://geode.apache.org/docs/guide/11/reference/topics/client-cache.html#cc-pdx
> Unfortunately, the example is WRONG, as it is using the "peer" cache element 
> tag ( instead of ), but this reference ([5]) is from 
> client-cache section...



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

[GitHub] geode pull request #486: GEODE-2830 Required permission for executing a func...

[davebarnes97]

Github user davebarnes97 closed the pull request at:

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


---
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-2830) Required permission for executing a function should be DATA:WRITE

[ASF GitHub Bot (JIRA)]

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

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

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/486
  
Merged


> Required permission for executing a function should be DATA:WRITE
> -
>
> Key: GEODE-2830
> URL: https://issues.apache.org/jira/browse/GEODE-2830
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Diane Hardman
>Assignee: Dave Barnes
>
> The required permission for executing a function as listed in the gfsh 
> command table (2nd table) is wrong in the docs:
> http://gemfire.docs.pivotal.io/geode/managing/security/implementing_authorization.html
> It is listed as DATA:MANAGE in the gfsh command table, but should be 
> DATA:WRITE.
> The correct permission is listed in the client operation table above the gfsh 
> table.



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

[GitHub] geode issue #486: GEODE-2830 Required permission for executing a function sh...

[davebarnes97]

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/486
  
Merged


---
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-2830) Required permission for executing a function should be DATA:WRITE

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2830:


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

GEODE-2830 Required permission for executing a function should be DATA:WRITE
This closes #485


> Required permission for executing a function should be DATA:WRITE
> -
>
> Key: GEODE-2830
> URL: https://issues.apache.org/jira/browse/GEODE-2830
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Diane Hardman
>Assignee: Dave Barnes
>
> The required permission for executing a function as listed in the gfsh 
> command table (2nd table) is wrong in the docs:
> http://gemfire.docs.pivotal.io/geode/managing/security/implementing_authorization.html
> It is listed as DATA:MANAGE in the gfsh command table, but should be 
> DATA:WRITE.
> The correct permission is listed in the client operation table above the gfsh 
> table.



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

[GitHub] geode pull request #485: GEODE-2843 User Guide - example should specify

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2843) User Guide - example should specify

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> User Guide - example should specify 
> --
>
> Key: GEODE-2843
> URL: https://issues.apache.org/jira/browse/GEODE-2843
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Excerpt from John Blum's response to a user's question:
> See the example here: 
> http://geode.apache.org/docs/guide/11/reference/topics/client-cache.html#cc-pdx
> Unfortunately, the example is WRONG, as it is using the "peer" cache element 
> tag ( instead of ), but this reference ([5]) is from 
> client-cache section...



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1996:


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

GEODE-1996 Confusing references to "multicast" for locators ports (wip)


> 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.docs.pivotal.io/docs/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-2843) User Guide - example should specify

[ASF GitHub Bot (JIRA)]

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

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

Github user joeymcallister commented on the issue:

https://github.com/apache/geode/pull/485
  
+1


> User Guide - example should specify 
> --
>
> Key: GEODE-2843
> URL: https://issues.apache.org/jira/browse/GEODE-2843
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Excerpt from John Blum's response to a user's question:
> See the example here: 
> http://geode.apache.org/docs/guide/11/reference/topics/client-cache.html#cc-pdx
> Unfortunately, the example is WRONG, as it is using the "peer" cache element 
> tag ( instead of ), but this reference ([5]) is from 
> client-cache section...



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

[GitHub] geode issue #485: GEODE-2843 User Guide - example should specify

[joeymcallister]

Github user joeymcallister commented on the issue:

https://github.com/apache/geode/pull/485
  
+1


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

[GitHub] geode issue #486: GEODE-2830 Required permission for executing a function sh...

[joeymcallister]

Github user joeymcallister commented on the issue:

https://github.com/apache/geode/pull/486
  
LGTM +1


---
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-2825) Lucene query may stackoverflow if enough function execution retries are executed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2825:


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

GEODE-2825: Lucene query function will wait until index is returned if an index 
is defined

  * If an index is in a defined state but not yet created, the query will now 
wait
until the index is created or no longer defined.  Instead of throwing an
exception and possibly getting a stack overflow


> Lucene query may stackoverflow if enough function execution retries are 
> executed
> 
>
> Key: GEODE-2825
> URL: https://issues.apache.org/jira/browse/GEODE-2825
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>
> It is possible that a LuceneQueryFunction fails to obtain the lucene index, 
> this will cause a retry.  If this occurs enough, a stack overflow will occur 
> based on the way the function execution code is currently written.
> Instead we can detect if the index has been defined, if so, wait until the 
> index is created.  This will cause the query to block/wait until the index is 
> ready.  It is possible to get stuck in a loop like this, but this scenario 
> should only occur when an index is being created but has yet to complete.



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

[jira] [Commented] (GEODE-2825) Lucene query may stackoverflow if enough function execution retries are executed

[ASF GitHub Bot (JIRA)]

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

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

Github user jhuynh1 closed the pull request at:

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


> Lucene query may stackoverflow if enough function execution retries are 
> executed
> 
>
> Key: GEODE-2825
> URL: https://issues.apache.org/jira/browse/GEODE-2825
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>
> It is possible that a LuceneQueryFunction fails to obtain the lucene index, 
> this will cause a retry.  If this occurs enough, a stack overflow will occur 
> based on the way the function execution code is currently written.
> Instead we can detect if the index has been defined, if so, wait until the 
> index is created.  This will cause the query to block/wait until the index is 
> ready.  It is possible to get stuck in a loop like this, but this scenario 
> should only occur when an index is being created but has yet to complete.



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

[GitHub] geode pull request #480: GEODE-2825: Lucene query waits for defined index to...

[jhuynh1]

Github user jhuynh1 closed the pull request at:

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


---
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-2852) Enforce WaitUntilFlushedFunction.waitUntilFlushed() timeout across all (local) buckets (not per bucket)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2852:


Commit 29fbd25cb3cb16a5c759a835402c60270e4f21cd in geode's branch 
refs/heads/feature/GEODE-2852 from [~lhughesgodfrey]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=29fbd25 ]

Merge remote-tracking branch 'origin/develop' into feature/GEODE-2852


> Enforce WaitUntilFlushedFunction.waitUntilFlushed() timeout across all 
> (local) buckets (not per bucket)
> ---
>
> Key: GEODE-2852
> URL: https://issues.apache.org/jira/browse/GEODE-2852
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> Currently, the timeout provided in LuceneServiceImpl.waitUntilFlushed() is 
> applied on a per bucket basis (in each member) within 
> BucketRegionQueue.waitUntilFlushed().
> This timeout needs to be applied across all (local primary) buckets 
> (WaitUntilParallelGatewaySenderFlushedCoordinator).  
> Once the timeout is reached, return false if all WaitUntilFlushed Callables 
> have not been invoked.



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

[jira] [Commented] (GEODE-2852) Enforce WaitUntilFlushedFunction.waitUntilFlushed() timeout across all (local) buckets (not per bucket)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2852:


Commit e94e506eb250ec51c8285897dbbcbe255a7910b1 in geode's branch 
refs/heads/feature/GEODE-2852 from [~lhughesgodfrey]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e94e506 ]

Merge remote-tracking branch 'origin/develop' into feature/GEODE-2852


> Enforce WaitUntilFlushedFunction.waitUntilFlushed() timeout across all 
> (local) buckets (not per bucket)
> ---
>
> Key: GEODE-2852
> URL: https://issues.apache.org/jira/browse/GEODE-2852
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> Currently, the timeout provided in LuceneServiceImpl.waitUntilFlushed() is 
> applied on a per bucket basis (in each member) within 
> BucketRegionQueue.waitUntilFlushed().
> This timeout needs to be applied across all (local primary) buckets 
> (WaitUntilParallelGatewaySenderFlushedCoordinator).  
> Once the timeout is reached, return false if all WaitUntilFlushed Callables 
> have not been invoked.



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

[jira] [Commented] (GEODE-2823) The LuceneEventListener caues deserialized values to be stored in the entry when the region contains DataSerializable or Serializable values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2823:


Commit 8da1ba353185c931d7d1626ca9e188b4f38d0761 in geode's branch 
refs/heads/feature/GEODE-2852 from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=8da1ba3 ]

GEODE-2823: The listener now forces a copy of the value to be made


> The LuceneEventListener caues deserialized values to be stored in the entry 
> when the region contains DataSerializable or Serializable values
> 
>
> Key: GEODE-2823
> URL: https://issues.apache.org/jira/browse/GEODE-2823
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> If the {{Region}} contains {{DataSerializable}} or {{Serializable}} values, 
> then each {{RegionEntry}} contains a {{VMCachedDeserializable}}. When 
> {{LuceneEventListener.process}} calls {{entry.getValue()}}, the value is 
> deserialized and left in that state in the {{VMCachedDeserializable}}.
> Below is a live histogram for the no index test.
> {noformat}
>  num #instances #bytes  class name
> --
>1:1019016088544  [B
>2:115600056  
> org.apache.geode.internal.cache.VersionedThinRegionEntryHeapStringKey1
>3: 363463236272  [C
>4:10240  
> org.apache.geode.internal.cache.VMCachedDeserializable
>5:  3792 905488  
> [Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
>6: 36161 867864  java.lang.String
>7:  6546 750464  java.lang.Class
>8:  8051 523264  [Ljava.lang.Object;
>9:  5151 453288  java.lang.reflect.Method
>   10:   704 405280  [J
>   11:  8390 402720  
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync
>   12: 11796 377472  
> java.util.concurrent.ConcurrentHashMap$Node
>   13: 11379 364128  java.util.HashMap$Node
>   14:   597 357552  
> [Ljava.util.concurrent.ConcurrentHashMap$Node;
>   15:  3409 319888  [Ljava.util.HashMap$Node;
>   16:  7754 310160  java.util.LinkedHashMap$Entry
>   17:  5817 279216  java.util.TreeMap
>   18:  4031 257984  java.util.concurrent.ConcurrentHashMap
>   19:  6385 255400  java.util.TreeMap$Entry
>   20: 13587 217392  java.lang.Object
> Total611397   28902304
> {noformat}
> Below is a live histogram for the index test. The main thing to notice 
> regarding this bug is the 10 Trade instances.
> {noformat}
>  num #instances #bytes  class name
> --
>1:338275   16181384  [C
>2:322931   15500688  
> org.apache.geode.internal.cache.TombstoneService$Tombstone
>3:220717   12360152  
> org.apache.geode.internal.cache.VersionedThinRegionEntryHeapObjectKey
>4:197837   11078872  
> org.apache.geode.internal.cache.VersionedThinRegionEntryHeapStringKey1
>5:3380368112864  java.lang.String
>6:3231287755072  
> java.util.concurrent.ConcurrentLinkedQueue$Node
>7: 205015658048  [B
>8:1626495204768  java.util.UUID
>9:1592753822600  
> org.apache.geode.cache.lucene.internal.filesystem.ChunkKey
>   10:  56003787016  
> [Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
>   11:10320  Trade
>   12:1034872483688  
> org.apache.geode.internal.cache.VMCachedDeserializable
>   13: 634942031808  java.util.HashMap$Node
>   14: 139741241616  [Ljava.util.HashMap$Node;
>   15: 254561221888  java.util.HashMap
>   16:  7396 843664  java.lang.Class
>   17: 10948 726856  [Ljava.lang.Object;
>   18: 11357 726848  
> org.apache.geode.internal.cache.VersionedThinRegionEntryHeapStringKey2
>   19: 15856 634240  java.util.TreeMap$Entry
>   20:  1067 614992  
> [Ljava.util.concurrent.ConcurrentHashMap$Node;
> Total   2856366  118323456
> {noformat}



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

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


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

GEODE-2632: prevent ClassCastException from ConnectionCountProbe to Identifiable


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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

[jira] [Commented] (GEODE-2795) Nightly build failure: CreateAlterDestroyRegionCommandsDUnitTest

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2795:


Commit 953f1eebcb0a1615bc761b684463fe890abe5692 in geode's branch 
refs/heads/feature/GEODE-2852 from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=953f1ee ]

GEODE-2795: Clean up DUnit VMs after dynamically changing 'user.dir'


> Nightly build failure: CreateAlterDestroyRegionCommandsDUnitTest
> 
>
> Key: GEODE-2795
> URL: https://issues.apache.org/jira/browse/GEODE-2795
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> It looks like the nightly build is failing due to polluted DUnit vms.  
> (FastClassPathScanner uses the Path api instead of the File api, and while 
> File accepts modified values of System.getProperty("user.dir"), Path does 
> not).
> {noformat}
> :geode-core:distributedTest
> org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommandsDUnitTest
>  > testAlterRegionResetCacheListeners FAILED
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 908
> [error 2017/04/18 10:12:26.647 UTC  
> tid=0x5d9] Could not deploy JAR file java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/server-1
> java.lang.RuntimeException: java.lang.RuntimeException: 
> java.nio.file.NoSuchFileException: /tmp/junit3985345267510453893/server-1
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1115)
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1143)
>   at 
> io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1166)
>   at 
> org.apache.geode.internal.DeployedJar.findFunctionsInThisJar(DeployedJar.java:328)
>   at 
> org.apache.geode.internal.DeployedJar.loadClassesAndRegisterFunctions(DeployedJar.java:175)
>   at 
> org.apache.geode.internal.JarDeployer.registerNewVersions(JarDeployer.java:477)
>   at org.apache.geode.internal.JarDeployer.deploy(JarDeployer.java:516)
>   at 
> org.apache.geode.management.internal.cli.functions.DeployFunction.execute(DeployFunction.java:68)
>   at 
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:191)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
>   at 
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1067)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: java.nio.file.NoSuchFileException: 
> /tmp/junit3985345267510453893/server-1
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:217)
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:61)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   ... 1 more
> Caused by: java.nio.file.NoSuchFileException: 
> /tmp/junit3985345267510453893/server-1
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at sun.nio.fs.UnixPath.toRealPath(UnixPath.java:876)
>   at 
> io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:215)
>   ... 5 more
> ---
> Found suspect string in log4j at line 945
> [error 2017/04/18 10:12:26.671 UTC  
> tid=0x5b1] Could not deploy JAR file java.lang.RuntimeException: 
> 

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

[Ken Howe]

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




geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQuery.java
Line 425 (original), 419 (patched)


but the exception is not ignored, so don't name it ignore



geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQuery.java
Line 580 (original), 559 (patched)


Rename ignore. Another case where the exception is not ignored



geode-core/src/main/java/org/apache/geode/cache/query/internal/ExecutionContext.java
Line 182 (original), 180 (patched)


I would leave the @link annotation intact



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryMonitor.java
Line 358 (original), 359 (patched)


Can you use a StringBHuilder here?



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Line 723 (original), 683 (patched)


Incomplete TODO comment. The line that was deleted:
// Object[] can be added rather than Struct



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 873 (patched)


remove empty block comment



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Line 1148 (original), 1086 (patched)


Typo: th -> the



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 1430-1439 (original), 1341-1350 (patched)


Formatting of this block of comments (and the one a dozen lines below) can 
be cleaned up



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 1539-1541 (original), 1448-1450 (patched)


comments canb be reformatted.



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 1580-1586 (original), 1489-1495 (patched)


more comment formatting



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 1588-1593 (original), 1497-1502 (patched)


more comment formatting


- Ken Howe


On May 2, 2017, 12:06 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 2, 2017, 12:06 a.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
> -
> 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/common/CacheProperty.java
>  fe16fc3bd85e5861205dcdac6583d32abe57fcac 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/filter/GemfireSessionManager.java
>  20cfecac2aaafd09c04eb6115a0da9c99201927b 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
>  edc2b7d8bfc684257c27d90d4b8d0c4db378347d 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/util/CreateRegionFunction.java
>  4e9e9fdf63eba622a157138e8e164956c257f093 
>   
> 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 
> 

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

[Ken Howe]

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




geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQuery.java
Line 425 (original), 419 (patched)


but the exception is not ignored, so don't name it ignore



geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQuery.java
Line 580 (original), 559 (patched)


Rename ignore. Another case where the exception is not ignored



geode-core/src/main/java/org/apache/geode/cache/query/internal/ExecutionContext.java
Line 182 (original), 180 (patched)


I would leave the @link annotation intact



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryMonitor.java
Line 358 (original), 359 (patched)


Can you use a StringBHuilder here?



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Line 723 (original), 683 (patched)


Incomplete TODO comment. The line that was deleted:
// Object[] can be added rather than Struct



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 873 (patched)


remove empty block comment



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Line 1148 (original), 1086 (patched)


Typo: th -> the



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 1430-1439 (original), 1341-1350 (patched)


Formatting of this block of comments (and the one a dozen lines below) can 
be cleaned up



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 1539-1541 (original), 1448-1450 (patched)


comments canb be reformatted.



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 1580-1586 (original), 1489-1495 (patched)


more comment formatting



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 1588-1593 (original), 1497-1502 (patched)


more comment formatting


- Ken Howe


On May 2, 2017, 12:06 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 2, 2017, 12:06 a.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
> -
> 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/common/CacheProperty.java
>  fe16fc3bd85e5861205dcdac6583d32abe57fcac 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/filter/GemfireSessionManager.java
>  20cfecac2aaafd09c04eb6115a0da9c99201927b 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
>  edc2b7d8bfc684257c27d90d4b8d0c4db378347d 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/util/CreateRegionFunction.java
>  4e9e9fdf63eba622a157138e8e164956c257f093 
>   
> 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 
> 

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

[Ken Howe]

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




geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQuery.java
Line 425 (original), 419 (patched)


but the exception is not ignored, so don't name it ignore



geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQuery.java
Line 580 (original), 559 (patched)


Rename ignore. Another case where the exception is not ignored



geode-core/src/main/java/org/apache/geode/cache/query/internal/ExecutionContext.java
Line 182 (original), 180 (patched)


I would leave the @link annotation intact



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryMonitor.java
Line 358 (original), 359 (patched)


Can you use a StringBHuilder here?



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Line 723 (original), 683 (patched)


Incomplete TODO comment. The line that was deleted:
// Object[] can be added rather than Struct



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 873 (patched)


remove empty block comment



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Line 1148 (original), 1086 (patched)


Typo: th -> the



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 1430-1439 (original), 1341-1350 (patched)


Formatting of this block of comments (and the one a dozen lines below) can 
be cleaned up



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 1539-1541 (original), 1448-1450 (patched)


comments canb be reformatted.



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 1580-1586 (original), 1489-1495 (patched)


more comment formatting



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Lines 1588-1593 (original), 1497-1502 (patched)


more comment formatting


- Ken Howe


On May 2, 2017, 12:06 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 2, 2017, 12:06 a.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
> -
> 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/common/CacheProperty.java
>  fe16fc3bd85e5861205dcdac6583d32abe57fcac 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/filter/GemfireSessionManager.java
>  20cfecac2aaafd09c04eb6115a0da9c99201927b 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
>  edc2b7d8bfc684257c27d90d4b8d0c4db378347d 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/util/CreateRegionFunction.java
>  4e9e9fdf63eba622a157138e8e164956c257f093 
>   
> 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 
> 

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

[Jared Stewart]

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




geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java
Line 3495 (original), 3214 (patched)


This can be simplified to: 
```
for (DistributedMember member : members) {
  Set roles = member.getRoles();
```


- Jared Stewart


On May 2, 2017, 12:06 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 2, 2017, 12:06 a.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
> -
> 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/common/CacheProperty.java
>  fe16fc3bd85e5861205dcdac6583d32abe57fcac 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/filter/GemfireSessionManager.java
>  20cfecac2aaafd09c04eb6115a0da9c99201927b 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
>  edc2b7d8bfc684257c27d90d4b8d0c4db378347d 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/util/CreateRegionFunction.java
>  4e9e9fdf63eba622a157138e8e164956c257f093 
>   
> 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 
>   
> 

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

[Jared Stewart]

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




geode-core/src/main/java/org/apache/geode/internal/cache/CacheServerImpl.java
Line 568 (original), 583 (patched)


This variable is unused.



geode-core/src/main/java/org/apache/geode/internal/cache/ColocationHelper.java
Line 137 (original), 139 (patched)


Why was `"/"` changed to `getLineSeparator()`?  I think that will return 
something like `\r\n` and change the behavior of this statement.


- Jared Stewart


On May 2, 2017, 12:06 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 2, 2017, 12:06 a.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
> -
> 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/common/CacheProperty.java
>  fe16fc3bd85e5861205dcdac6583d32abe57fcac 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/filter/GemfireSessionManager.java
>  20cfecac2aaafd09c04eb6115a0da9c99201927b 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
>  edc2b7d8bfc684257c27d90d4b8d0c4db378347d 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/util/CreateRegionFunction.java
>  4e9e9fdf63eba622a157138e8e164956c257f093 
>   
> 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 
>  

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

[Spring CI]

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

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





--
This message is automatically generated by Atlassian Bamboo

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

[Bruce Schuchardt]

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

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/1/


Testing
---

passes precheckin and modified unit tests


Thanks,

Bruce Schuchardt

[jira] [Resolved] (GEODE-2753) Create class diagram

[Addison (JIRA)]

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

Addison resolved GEODE-2753.

Resolution: Won't Do

> Create class diagram
> 
>
> Key: GEODE-2753
> URL: https://issues.apache.org/jira/browse/GEODE-2753
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Addison
>
> Create a mapping of classes in the Native Client



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

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

[Jared Stewart]

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




geode-core/src/main/java/org/apache/geode/internal/admin/ClientHealthMonitoringRegion.java
Line 55 (original), 54 (patched)


Again unrelated to your changes, but this looks weird as line 57 does a 
null check on `cache`, but line 54 would throw a NPE if that were true 
(assuming that it didn't get short circuited).


- Jared Stewart


On May 2, 2017, 12:06 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 2, 2017, 12:06 a.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
> -
> 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/common/CacheProperty.java
>  fe16fc3bd85e5861205dcdac6583d32abe57fcac 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/filter/GemfireSessionManager.java
>  20cfecac2aaafd09c04eb6115a0da9c99201927b 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
>  edc2b7d8bfc684257c27d90d4b8d0c4db378347d 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/util/CreateRegionFunction.java
>  4e9e9fdf63eba622a157138e8e164956c257f093 
>   
> 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
>  

[jira] [Created] (GEODE-2865) data loss in initial-image replication with multicast

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-2865:
---

 Summary: data loss in initial-image replication with multicast
 Key: GEODE-2865
 URL: https://issues.apache.org/jira/browse/GEODE-2865
 Project: Geode
  Issue Type: Bug
  Components: messaging
Reporter: Bruce Schuchardt


During initial image replication ("get initial image") a state-flush operation 
is performed to ensure that all in-flight operations are applied to the region 
being replicated prior to replication starting.  If multicast is enabled for a 
region it is currently possible for the state-flush to miss one or more 
in-flight operations, so that the new repilcate is missing changes that are 
reflected in the region being replicated.

For example, process A sends a multicast put() replication message to process 
B.  Simultaneously process C is replicating the affected region and performs a 
state-flush.  Process A sends a state-stabilization message to process B noting 
its multicast channel state (NAKACK2 outgoing message counter).  Process B 
receives this and waits for the multicast channel state to show that it has 
received all of the messages.  Process B then sends a state-stabilized message 
to process C (the new replicate).

The state-stabilization algorithm in this case is faulty because it is 
performed in the waiting-thread pool.  The algorithm assumes that it is 
executing in the serial-executor thread pool so that any messages that happened 
before it have been applied to the region.  This can allow messages to have 
been received and scheduled for the serial-executor but not be applied to the 
region before replication begins.

The membership manager should be modified to ensure that the serial-executor 
queue has been flushed before giving the state-flush operation the go-ahead to 
begin replication.



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

[jira] [Commented] (GEODE-2825) Lucene query may stackoverflow if enough function execution retries are executed

[ASF GitHub Bot (JIRA)]

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

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

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/480
  
Sure, I can re-add the one second sleep.


> Lucene query may stackoverflow if enough function execution retries are 
> executed
> 
>
> Key: GEODE-2825
> URL: https://issues.apache.org/jira/browse/GEODE-2825
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>
> It is possible that a LuceneQueryFunction fails to obtain the lucene index, 
> this will cause a retry.  If this occurs enough, a stack overflow will occur 
> based on the way the function execution code is currently written.
> Instead we can detect if the index has been defined, if so, wait until the 
> index is created.  This will cause the query to block/wait until the index is 
> ready.  It is possible to get stuck in a loop like this, but this scenario 
> should only occur when an index is being created but has yet to complete.



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

[GitHub] geode issue #480: GEODE-2825: Lucene query waits for defined index to be cre...

[jhuynh1]

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/480
  
Sure, I can re-add the one second sleep.


---
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 58888: GEODE-2632: change dependencies on GemFireCacheImpl to InternalCache

[Jared Stewart]

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




geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryExecutionContext.java
Line 41 (original), 42 (patched)


Not directly related to your changes, but this variable is assigned to and 
never read from.



geode-core/src/main/java/org/apache/geode/distributed/internal/ClusterConfigurationService.java
Line 441 (original), 449 (patched)


The `(String)` casts on 449 and 451 are redundant.



geode-core/src/main/java/org/apache/geode/distributed/internal/InternalLocator.java
Line 1230 (original), 1187 (patched)


This looks like a possible bug, as this will always return true no matter 
the value of `status`.


- Jared Stewart


On May 2, 2017, 12:06 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 2, 2017, 12:06 a.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
> -
> 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/common/CacheProperty.java
>  fe16fc3bd85e5861205dcdac6583d32abe57fcac 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/filter/GemfireSessionManager.java
>  20cfecac2aaafd09c04eb6115a0da9c99201927b 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
>  edc2b7d8bfc684257c27d90d4b8d0c4db378347d 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/util/CreateRegionFunction.java
>  4e9e9fdf63eba622a157138e8e164956c257f093 
>   
> 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 
>   
> 

Re: Hit/Miss counts

[Darrel Schneider]

I think the problem on gfsh show metrics is caused by GEODE-2676. Since it
talks about mbeans it would be helpful if you added to it how it impacts
the gfsh show metrics command.
Currently PartiionedRegions do not support hit/miss count. Vote
for: GEODE-2685.

I think the totalHit/Miss count incing by two instead of one is an unfiled
bug. Internally PRs are implemented by both ParitionedRegion and
BucketRegion. Perhaps each of these is incrementing.


On Tue, May 2, 2017 at 2:15 PM, Srikanth Manvi  wrote:

> Hello Geode Community,
>
>
> I am creating 2 regions, one is of type=PARTITION and the other is of the
> type=LOCAL and observe the following
>
> - "*totalHitCount"* and "*totalMissCount"* jumps by 2 for every hit/miss
> for Partitioned region and it jumps by 1 for the local region. Is this by
> design (if so, whats the reasoning behind it) or a bug ?
>
> - The *"hitCount"* and *"missCount"* for a partitioned region always
> (at-least in my simple test) displays -1, So is there no way to know the
> correct hit/miss counts for partitioned regions ?
>
> - When I run the *show metrics* command by specifying a member (*gfsh>show
> metrics --region=/Customer_Partition --member=geode-server2*)  I get a NPE
> (stacktrace below).
>
>
> Please let me know if any of the above needs a JIRA, I can create one.
>
>
> *gfsh>create region --name=Customer_Partition --enable-statistics=true
> --type=PARTITION*
>
> *gfsh>create region --name=Customer_Local --enable-statistics=true
> --type=LOCAL*
> *gfsh>get --key=404 --region=/Customer_Partition*
>
> Result  : false
>
> *gfsh>show metrics*
>
> Cluster-wide Metrics
>
> Category  |Metric | Value
>
> - | - | -
>
> cluster   | totalHeapSize | 10923
>
> cache | totalRegionEntryCount | 0
>
>   | totalRegionCount  | 5
>
> *  | totalMissCount| 2*
>
>
> *gfsh>get --key=404 --region=/Customer_Local*
>
> Result  : false
>
> *gfsh>show metrics*
>
> Cluster-wide Metrics
>
> Category  |Metric | Value
>
> - | - | -
>
> cluster   | totalHeapSize | 10923
>
> cache | totalRegionEntryCount | 0
>
>   | totalRegionCount  | 5
> *  | totalMissCount| 3*
>
>
> *gfsh>put --key=1 --value="1" --region=/Customer*
> *gfsh>put --key=1 --value="1" --region=/Customer_Local*
>
>
> gfsh>get --key=1 --region=/Customer_Partition
> Result  : true
>
> *gfsh>show metrics --region=/Customer_Partition*
> Cluster-wide Region Metrics
>
> Category  |Metric| Value
> - |  | -
> cluster   | member count | 1
>   | region entry count   | 1
> region| lastModifiedTime | -1
>   | lastAccessedTime | -1
> *  | missCount| -1*
> *  | hitCount | -1*
>   | hitRatio | -1
>
>
> *gfsh>show metrics --region=/Customer_Partition --member=geode-server2*
> Could not process command due to GemFire error.
> #SBjava.lang.NullPointerException
> at com.sun.proxy.$Proxy81.getMissCount(Unknown Source)
> at
> org.apache.geode.management.internal.cli.commands.MiscellaneousCommands.
> getRegionMetricsFromMember(MiscellaneousCommands.java:1970)
> at
> org.apache.geode.management.internal.cli.commands.MiscellaneousCommands.
> showMetrics(MiscellaneousCommands.java:1200)
> 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.springframework.util.ReflectionUtils.invokeMethod(
> ReflectionUtils.java:216)
> at
> org.apache.geode.management.internal.cli.remote.RemoteExecutionStrategy.
> execute(RemoteExecutionStrategy.java:91)
> at
> org.apache.geode.management.internal.cli.remote.CommandProcessor.
> executeCommand(CommandProcessor.java:117)
> at
> org.apache.geode.management.internal.cli.remote.
> CommandStatementImpl.process(CommandStatementImpl.java:71)
> at
> org.apache.geode.management.internal.cli.remote.MemberCommandService.
> processCommand(MemberCommandService.java:52)
> at
> org.apache.geode.management.internal.beans.MemberMBeanBridge.
> processCommand(MemberMBeanBridge.java:1639)
> at
> org.apache.geode.management.internal.beans.MemberMBean.
> processCommand(MemberMBean.java:404)
> at
> org.apache.geode.management.internal.beans.MemberMBean.
> processCommand(MemberMBean.java:397)
> at sun.reflect.GeneratedMethodAccessor298.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 

[jira] [Updated] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan updated GEODE-2859:

Fix Version/s: (was: 1.2.0)

> ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
> 
>
> Key: GEODE-2859
> URL: https://issues.apache.org/jira/browse/GEODE-2859
> Project: Geode
>  Issue Type: Test
>  Components: gfsh, membership, messaging, tests
>Reporter: Galen O'Sullivan
>
> https://builds.apache.org/job/Geode-nightly/821/
> This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was 
> recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). 
> Probably it needs the same fix or related.
> ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run.
> {code}
> Error Message
> java.lang.AssertionError
> Stacktrace
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction(ShowDeadlockDUnitTest.java:156)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 

[jira] [Resolved] (GEODE-2778) gfsh help now uses log4j log levels: update user guide

[Dave Barnes (JIRA)]

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

Dave Barnes resolved GEODE-2778.

Resolution: Fixed

> gfsh help now uses log4j log levels: update user guide
> --
>
> Key: GEODE-2778
> URL: https://issues.apache.org/jira/browse/GEODE-2778
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, gfsh
>Reporter: Dave Barnes
>Assignee: Dave Barnes
> Fix For: 1.2.0
>
>
> Update the user guide to reflect this change.



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

[jira] [Assigned] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan reassigned GEODE-2859:
---

Assignee: (was: Galen O'Sullivan)

> ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
> 
>
> Key: GEODE-2859
> URL: https://issues.apache.org/jira/browse/GEODE-2859
> Project: Geode
>  Issue Type: Test
>  Components: gfsh, membership, messaging, tests
>Reporter: Galen O'Sullivan
> Fix For: 1.2.0
>
>
> https://builds.apache.org/job/Geode-nightly/821/
> This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was 
> recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). 
> Probably it needs the same fix or related.
> ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run.
> {code}
> Error Message
> java.lang.AssertionError
> Stacktrace
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction(ShowDeadlockDUnitTest.java:156)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 

[jira] [Updated] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan updated GEODE-2859:

Description: 
https://builds.apache.org/job/Geode-nightly/821/

This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was 
recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). 
Probably it needs the same fix or related.

ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run.

{code}
Error Message

java.lang.AssertionError

Stacktrace

java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.geode.management.internal.cli.commands.ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction(ShowDeadlockDUnitTest.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
at 
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at 
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at 
org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
at 

[jira] [Commented] (GEODE-2778) gfsh help now uses log4j log levels: update user guide

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> gfsh help now uses log4j log levels: update user guide
> --
>
> Key: GEODE-2778
> URL: https://issues.apache.org/jira/browse/GEODE-2778
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, gfsh
>Reporter: Dave Barnes
>Assignee: Dave Barnes
> Fix For: 1.2.0
>
>
> Update the user guide to reflect this change.



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

[GitHub] geode pull request #484: GEODE-2778: gfsh help now uses log4j log levels: up...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2778) gfsh help now uses log4j log levels: update user guide

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2778:


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

GEODE-2778: gfsh help now uses log4j log levels: update user guide
This closes #484


> gfsh help now uses log4j log levels: update user guide
> --
>
> Key: GEODE-2778
> URL: https://issues.apache.org/jira/browse/GEODE-2778
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, gfsh
>Reporter: Dave Barnes
>Assignee: Dave Barnes
> Fix For: 1.2.0
>
>
> Update the user guide to reflect this change.



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

[jira] [Updated] (GEODE-2676) RegionMBean statistics wrong on partitioned regions

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-2676:

Component/s: management

> RegionMBean statistics wrong on partitioned regions
> ---
>
> Key: GEODE-2676
> URL: https://issues.apache.org/jira/browse/GEODE-2676
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Fred Krone
>Priority: Minor
>  Labels: jmx
>
> RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and 
> lastModifiedTime will always be 0 for an mbean that represents an partitioned 
> region.
> The gettors for these methods may call getStatistics() which on a PR always 
> throws UnsupportedOperationException. So this exception might even get 
> exposed to customers.
> The initialization of RegionMBeanBridge calls getStatisticsEnabled() which 
> returns true on a PartitionedRegion. This does have meaning on a PR but it 
> does not mean that getStatistics() is a supported operation. On a PR setting 
> statistics-enabled causes each region-entry to also keep track of its last 
> access time.
> It is true that if getStatisticsEnabled() is false then you should not call 
> getStatistics. But the opposite is not true. Since we currently have regions 
> that do not support getStatistics(), the code in RegionMBeanBridge should 
> catch UnsupportedOperationException and handle it. I would suggest that the 
> constructor be changed that initializes the "isStatisticsEnabled" field. 
> Instead of only calling getStatisticsEnabled() it should also call 
> getStatistics(). Something like this:
> {noformat}
> {
>   boolean useGetStatistics = regAttrs.getStatisticsEnabled();
>   if (useGetStatistics) {
> try {
>   region.getStatistics();
> } catch (UnsupportedOperationException ex) {
>   useGetStatistics = false;
> }
>   }
>   this.isStatisticsEnabled = useGetStatistics;
> }
> {noformat}
> That way in a future release if PRs are changed to support getStatistics this 
> code will start calling it without having a direct dependency on the 
> implementation of PartitionedRegion.
> https://issues.apache.org/jira/browse/GEODE-2685 is a request to support 
> getStatistics on PRs.



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

[jira] [Assigned] (GEODE-2824) FunctionException: No target node found when executing hasNext on Lucene result

[xiaojian zhou (JIRA)]

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

xiaojian zhou reassigned GEODE-2824:


Assignee: xiaojian zhou

> FunctionException: No target node found when executing hasNext on Lucene 
> result
> ---
>
> Key: GEODE-2824
> URL: https://issues.apache.org/jira/browse/GEODE-2824
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: xiaojian zhou
>
> The stack trace below is thrown during a race condition when a node is 
> closing and calling hasNext on a Lucene result.
> It looks there was a CacheClosedException, but this execution was unable to 
> find a target node to retry on.  This execution then threw a 
> FunctionException.
> We have code to unwrap CacheClosedExceptions from function exceptions, 
> however this was just an ordinary function exception.  The underlying cause 
> is that the cache is closing at this time.
> We should probably wrap all function exceptions with either a 
> LuceneQueryException or equivalent as a user would probably not expect a 
> FunctionException when calling Lucene methods.
> The stack trace:
> {noformat}
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeOnMultipleNodes(PartitionedRegion.java:3459)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeFunction(PartitionedRegion.java:3367)
> at 
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.executeFunction(PartitionedRegionFunctionExecutor.java:228)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:376)
> at 
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:178)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.getValues(PageableLuceneQueryResultsImpl.java:112)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.getHitEntries(PageableLuceneQueryResultsImpl.java:91)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.advancePage(PageableLuceneQueryResultsImpl.java:139)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.hasNext(PageableLuceneQueryResultsImpl.java:148)
> {noformat}



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

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

[Udo Kohlmeyer]

We are considering the function service, but again, this should not 
detract from the proposed message specification proposal.


You are also correct in your observation of list of error codes not 
being complete nor exhaustive. Maybe the first page needs to highlight 
that this is a proposal and does not contain all the error codes that we 
could per api.


As for the EventId, we will look into this and update the document 
accordingly.


--Udo


On 5/2/17 13:42, Dan Smith wrote:
I guess the value of building other messages on top of the function 
service mostly comes into play when we start talking about smarter 
clients that can do single hop. At that point it's really nice to have 
have a layer that lets us send a message to a single primary, or all 
of the members that host a region etc. It is also nice that right now 
if I add new function that functionality becomes available to gfsh, 
REST, Java, and C++ developers automatically.


I do agree that the new protocol could build in these concepts, and 
doesn't necessarily have to use function execution to achieve the same 
results. But do at least consider whether new developers will want to 
add new functionality to the server via functions or via your this new 
protocol. If it's harder to use the new protocol than to write a new 
function and invoke it from the client, then I think we've done 
something wrong.



A couple of other comments, now that I've looked a little more:

1) The list of error codes 
 
seems really incomplete. It looks like we've picked a few of the 
possible exceptions geode could throw and assigned them integer ids? 
What is the rational for the exceptions that are included here vs. 
other exceptions? Also, not all messages would need to return these 
error codes.


2) The existing protocol has some functionality even for basic puts 
that is not represented here. Client generate an event id that is 
associated with the put and send that to the server. These event ids 
are used to guarantee that if a client does put (A, 0) followed by put 
(A, 1), the resulting value will always be 1, even if the client timed 
out and retried put (A, 0). The event id prevents the lingered put 
that timed out on the server from affecting the state. I'm not saying 
the new protocol has to support this sort of behavior, but you might 
want to consider whether the current protocol should specify anything 
about how events are retried.


-Dan

[jira] [Updated] (GEODE-2864) In same cases committing a geode transaction logs a meaningless warning

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-2864:

Priority: Trivial  (was: Major)

> In same cases committing a geode transaction logs a meaningless warning
> ---
>
> Key: GEODE-2864
> URL: https://issues.apache.org/jira/browse/GEODE-2864
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Trivial
>
> Sometimes a transaction commit will log a warning message that looks like 
> this:
> {code}
> [warning 2017/04/27 17:11:15.034 CST GemfireAPIServer2  port 40405 Thread 0> tid=0x59] New members for Region: 
> com.gemstone.gemfire.internal.cache.DistributedRegion[path='/exampleRegionRep1';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
>  concurrencyChecksEnabled] orig list: 
> [pivhdsne(GemfireAPIServer1:79899):1265] new list: 
> [pivhdsne(GemfireAPIServer4:80172):56801, 
> pivhdsne(GemfireAPIServer1:79899):1265, 
> pivhdsne(GemfireAPIServer3:80078):14603]
> {code}
> This warning can be safely ignored.



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

Hit/Miss counts

[Srikanth Manvi]

Hello Geode Community,


I am creating 2 regions, one is of type=PARTITION and the other is of the
type=LOCAL and observe the following

- "*totalHitCount"* and "*totalMissCount"* jumps by 2 for every hit/miss
for Partitioned region and it jumps by 1 for the local region. Is this by
design (if so, whats the reasoning behind it) or a bug ?

- The *"hitCount"* and *"missCount"* for a partitioned region always
(at-least in my simple test) displays -1, So is there no way to know the
correct hit/miss counts for partitioned regions ?

- When I run the *show metrics* command by specifying a member (*gfsh>show
metrics --region=/Customer_Partition --member=geode-server2*)  I get a NPE
(stacktrace below).


Please let me know if any of the above needs a JIRA, I can create one.


*gfsh>create region --name=Customer_Partition --enable-statistics=true
--type=PARTITION*

*gfsh>create region --name=Customer_Local --enable-statistics=true
--type=LOCAL*
*gfsh>get --key=404 --region=/Customer_Partition*

Result  : false

*gfsh>show metrics*

Cluster-wide Metrics

Category  |Metric | Value

- | - | -

cluster   | totalHeapSize | 10923

cache | totalRegionEntryCount | 0

  | totalRegionCount  | 5

*  | totalMissCount| 2*


*gfsh>get --key=404 --region=/Customer_Local*

Result  : false

*gfsh>show metrics*

Cluster-wide Metrics

Category  |Metric | Value

- | - | -

cluster   | totalHeapSize | 10923

cache | totalRegionEntryCount | 0

  | totalRegionCount  | 5
*  | totalMissCount| 3*


*gfsh>put --key=1 --value="1" --region=/Customer*
*gfsh>put --key=1 --value="1" --region=/Customer_Local*


gfsh>get --key=1 --region=/Customer_Partition
Result  : true

*gfsh>show metrics --region=/Customer_Partition*
Cluster-wide Region Metrics

Category  |Metric| Value
- |  | -
cluster   | member count | 1
  | region entry count   | 1
region| lastModifiedTime | -1
  | lastAccessedTime | -1
*  | missCount| -1*
*  | hitCount | -1*
  | hitRatio | -1


*gfsh>show metrics --region=/Customer_Partition --member=geode-server2*
Could not process command due to GemFire error.
#SBjava.lang.NullPointerException
at com.sun.proxy.$Proxy81.getMissCount(Unknown Source)
at
org.apache.geode.management.internal.cli.commands.MiscellaneousCommands.getRegionMetricsFromMember(MiscellaneousCommands.java:1970)
at
org.apache.geode.management.internal.cli.commands.MiscellaneousCommands.showMetrics(MiscellaneousCommands.java:1200)
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.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
at
org.apache.geode.management.internal.cli.remote.RemoteExecutionStrategy.execute(RemoteExecutionStrategy.java:91)
at
org.apache.geode.management.internal.cli.remote.CommandProcessor.executeCommand(CommandProcessor.java:117)
at
org.apache.geode.management.internal.cli.remote.CommandStatementImpl.process(CommandStatementImpl.java:71)
at
org.apache.geode.management.internal.cli.remote.MemberCommandService.processCommand(MemberCommandService.java:52)
at
org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1639)
at
org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:404)
at
org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:397)
at sun.reflect.GeneratedMethodAccessor298.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at
com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
at
com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
at
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
at
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
at

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

[Jared Stewart]

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




geode-core/src/main/java/org/apache/geode/cache/query/internal/index/RangeIndex.java
Line 1081 (original), 1081 (patched)


The assignment inside of this if-statement offends my sensibilities.  I 
would much prefer something like this instead:

```
if (entriesMap == null || result == null) {
  if (verifyLimit(result, limit)) {
QueryObserver observer = QueryObserverHolder.getInstance();
if (observer != null) {
  observer.limitAppliedAtIndexLevel(this, limit, result);
}
  }
  return;
```


- Jared Stewart


On May 2, 2017, 12:06 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 2, 2017, 12:06 a.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
> -
> 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/common/CacheProperty.java
>  fe16fc3bd85e5861205dcdac6583d32abe57fcac 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/filter/GemfireSessionManager.java
>  20cfecac2aaafd09c04eb6115a0da9c99201927b 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
>  edc2b7d8bfc684257c27d90d4b8d0c4db378347d 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/util/CreateRegionFunction.java
>  4e9e9fdf63eba622a157138e8e164956c257f093 
>   
> 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 
>   
> 

[jira] [Assigned] (GEODE-2864) In same cases committing a geode transaction logs a meaningless warning

[Darrel Schneider (JIRA)]

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

Darrel Schneider reassigned GEODE-2864:
---

Assignee: Darrel Schneider

> In same cases committing a geode transaction logs a meaningless warning
> ---
>
> Key: GEODE-2864
> URL: https://issues.apache.org/jira/browse/GEODE-2864
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> Sometimes a transaction commit will log a warning message that looks like 
> this:
> {code}
> [warning 2017/04/27 17:11:15.034 CST GemfireAPIServer2  port 40405 Thread 0> tid=0x59] New members for Region: 
> com.gemstone.gemfire.internal.cache.DistributedRegion[path='/exampleRegionRep1';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
>  concurrencyChecksEnabled] orig list: 
> [pivhdsne(GemfireAPIServer1:79899):1265] new list: 
> [pivhdsne(GemfireAPIServer4:80172):56801, 
> pivhdsne(GemfireAPIServer1:79899):1265, 
> pivhdsne(GemfireAPIServer3:80078):14603]
> {code}
> This warning can be safely ignored.



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

[jira] [Updated] (GEODE-2864) In same cases committing a geode transaction logs a meaningless warning

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-2864:

Affects Version/s: 1.0.0-incubating

> In same cases committing a geode transaction logs a meaningless warning
> ---
>
> Key: GEODE-2864
> URL: https://issues.apache.org/jira/browse/GEODE-2864
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> Sometimes a transaction commit will log a warning message that looks like 
> this:
> {code}
> [warning 2017/04/27 17:11:15.034 CST GemfireAPIServer2  port 40405 Thread 0> tid=0x59] New members for Region: 
> com.gemstone.gemfire.internal.cache.DistributedRegion[path='/exampleRegionRep1';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
>  concurrencyChecksEnabled] orig list: 
> [pivhdsne(GemfireAPIServer1:79899):1265] new list: 
> [pivhdsne(GemfireAPIServer4:80172):56801, 
> pivhdsne(GemfireAPIServer1:79899):1265, 
> pivhdsne(GemfireAPIServer3:80078):14603]
> {code}
> This warning can be safely ignored.



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

[jira] [Created] (GEODE-2864) In same cases committing a geode transaction logs a meaningless warning

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2864:
---

 Summary: In same cases committing a geode transaction logs a 
meaningless warning
 Key: GEODE-2864
 URL: https://issues.apache.org/jira/browse/GEODE-2864
 Project: Geode
  Issue Type: Bug
  Components: transactions
Reporter: Darrel Schneider


Sometimes a transaction commit will log a warning message that looks like this:
{code}
[warning 2017/04/27 17:11:15.034 CST GemfireAPIServer2  tid=0x59] New members for Region: 
com.gemstone.gemfire.internal.cache.DistributedRegion[path='/exampleRegionRep1';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
 concurrencyChecksEnabled] orig list: 
[pivhdsne(GemfireAPIServer1:79899):1265] new list: 
[pivhdsne(GemfireAPIServer4:80172):56801, 
pivhdsne(GemfireAPIServer1:79899):1265, 
pivhdsne(GemfireAPIServer3:80078):14603]
{code}

This warning can be safely ignored.



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

Re: Requesting Commenting Access to Geode Confluence wiki for Binary Protocol Proposal

[Dan Smith]

Hi Matt,

I've added you - you should have access to comment now.

-Dan

On Mon, May 1, 2017 at 1:35 PM, Matt Kalinowski 
wrote:

> Hello,
>
> I was invited to review the proposal for the new binary client-server
> protocol (
> https://cwiki.apache.org/confluence/display/GEODE/New+
> Client+Server+Protocol)
> and would like to add comments to the documents/pages as part of the
> review. It appears I do not have commenting access. My username is
> `mkalinowski` and my email account is this one, `mkalinow...@pivotal.io`
>
> Thanks,
> Matt Kalinowski
>

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

[Dan Smith]

I guess the value of building other messages on top of the function service
mostly comes into play when we start talking about smarter clients that can
do single hop. At that point it's really nice to have have a layer that
lets us send a message to a single primary, or all of the members that host
a region etc. It is also nice that right now if I add new function that
functionality becomes available to gfsh, REST, Java, and C++ developers
automatically.

I do agree that the new protocol could build in these concepts, and doesn't
necessarily have to use function execution to achieve the same results. But
do at least consider whether new developers will want to add new
functionality to the server via functions or via your this new protocol. If
it's harder to use the new protocol than to write a new function and invoke
it from the client, then I think we've done something wrong.


A couple of other comments, now that I've looked a little more:

1) The list of error codes

seems really incomplete. It looks like we've picked a few of the possible
exceptions geode could throw and assigned them integer ids? What is the
rational for the exceptions that are included here vs. other exceptions?
Also, not all messages would need to return these error codes.

2) The existing protocol has some functionality even for basic puts that is
not represented here. Client generate an event id that is associated with
the put and send that to the server. These event ids are used to guarantee
that if a client does put (A, 0) followed by put (A, 1), the resulting
value will always be 1, even if the client timed out and retried put (A,
0). The event id prevents the lingered put that timed out on the server
from affecting the state. I'm not saying the new protocol has to support
this sort of behavior, but you might want to consider whether the current
protocol should specify anything about how events are retried.

-Dan

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

[Jared Stewart]

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




geode-core/src/main/java/org/apache/geode/cache/query/internal/index/CompactRangeIndex.java
Line 468 (original), 460 (patched)


This wasn't touched by your changes, but `multiColOrderBy` is written to 
but never read.



geode-core/src/main/java/org/apache/geode/cache/query/internal/index/CompactRangeIndex.java
Line 497 (original), 489 (patched)


Another `.booleanValue()` call to be removed here.



geode-core/src/main/java/org/apache/geode/cache/query/internal/index/HashIndex.java
Line 549 (original), 483 (patched)


These two booleans (`asc` and `multiColOrderBy`) are written to but never 
read from.


- Jared Stewart


On May 2, 2017, 12:06 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 2, 2017, 12:06 a.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
> -
> 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/common/CacheProperty.java
>  fe16fc3bd85e5861205dcdac6583d32abe57fcac 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/filter/GemfireSessionManager.java
>  20cfecac2aaafd09c04eb6115a0da9c99201927b 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
>  edc2b7d8bfc684257c27d90d4b8d0c4db378347d 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/util/CreateRegionFunction.java
>  4e9e9fdf63eba622a157138e8e164956c257f093 
>   
> 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 
>   
> 

[jira] [Updated] (GEODE-2862) shutdown hook does not wait for disk store async tasks to complete

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-2862:

Affects Version/s: 1.0.0-incubating

> shutdown hook does not wait for disk store async tasks to complete
> --
>
> Key: GEODE-2862
> URL: https://issues.apache.org/jira/browse/GEODE-2862
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>
> If you do a normal cache close and are using persistence then each disk store 
> close will wait for all of its async background tasks to complete.
> But if instead the JVM shutdown hook is used (see 
> java.lang.Runtime.addShutdownHook(Thread) for a description of what causes 
> the shutdown hook to be called) then it will not wait for the async 
> persistent tasks to complete.
> Both of these types of shutdown are considered an orderly shutdown (as 
> opposed to a unorderly shutdown caused by things like a kill -9) and geode 
> should only have one type of orderly shutdown. By not waiting for the async 
> persistent tasks to complete some files may never be fully written.
> Here is the code that causes the shutdown hook to not wait in DiskStoreImpl:
> {code}
>   // don't block the shutdown hook
>   if (Thread.currentThread() != InternalDistributedSystem.shutdownHook) {
> waitForBackgroundTasks();
>   }
> {code}



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

[jira] [Updated] (GEODE-2861) remove deadcode in GemFireCacheImpl and DiskStoreImpl for DiskStoreTaskPool

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-2861:

Affects Version/s: 1.0.0-incubating

> remove deadcode in GemFireCacheImpl and DiskStoreImpl for DiskStoreTaskPool
> ---
>
> Key: GEODE-2861
> URL: https://issues.apache.org/jira/browse/GEODE-2861
> Project: Geode
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>Priority: Trivial
>
> Both GemFireCacheImpl and DiskStoreImpl have deadcode related to shutting 
> down the DiskStoreTaskPool.
> On DiskStoreImpl see these methods:
>   stopDiskStoreTaskPool
>   shutdownPool
> On GemFireCacheImpl the field diskStoreTaskPool is always null.
> Note that a bug exists in this deadcode that causes it to not call 
> taskCancelled as it iterates over a list of runnables. Since this code is 
> dead it is currently doing no harm but if the code is not removed then make 
> sure and fix this loop.



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

[jira] [Created] (GEODE-2863) DiskStoreImpl close does not shutdown its thread pools

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2863:
---

 Summary: DiskStoreImpl close does not shutdown its thread pools
 Key: GEODE-2863
 URL: https://issues.apache.org/jira/browse/GEODE-2863
 Project: Geode
  Issue Type: Bug
  Components: persistence
Reporter: Darrel Schneider


Closing a DiskStoreImpl does not shutdown its thread pools.
It has two pools, "diskStoreTaskPool" and "delayedWritePool", that it does not 
shutdown.
However at least in some cases (see GEODE-2862) it does wait for all the tasks 
submitted to these pools to complete. But it is not clear if additional tasks 
could still be submitted after this wait is done.
Some logic should be added that causes the code that would submit a task to 
these executors to no longer do so or, if needed, to process the task inline.



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

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

[Hitesh Khamesra]

Absolutely its a implementation detail.
JSON: Surely we can consider ValueHeader. But then every client(and message) 
needs to send that. Using metadata its a optional.


  From: Dan Smith 
 To: Udo Kohlmeyer  
Cc: dev@geode.apache.org
 Sent: Tuesday, May 2, 2017 11:39 AM
 Subject: Re: [gemfire-dev] New Client-Server Protocol Proposal
   
> IsPartialMessage: This flag gives us ability to send partial message
> without serializing the whole key-value(request). lets say I execute
> function at server and function just returns "arraylist of object". And the
> serialized size of ""arraylist of object"" is quite big( > 2gb).
>

My point about these fields is that it really seems like this stuff should
be handled by different layers. Ideally you would have a fragmentation
layer that is invisible to people writing specific messages, so that
messages are automatically fragmented if they get to large. Think about how
a TCP socket works - you just write data and it is automatically
fragmented. Or are you expecting each individual message type to have it's
own way to doing fragmentation, but it should set this header down in your
protocol layer? That seems really messy.

JSON: this is a feature we want to introduce, where client can send JSON
> string and we want to save that JSON string into pdx.


Same thing here, JSON support sounds great, but having a header field of
JSON_KEY seems like a hacky way to do that. It seems like that might belong
in your ValueHeader.




On Tue, May 2, 2017 at 10:20 AM, Udo Kohlmeyer 
wrote:

> Hey Dan,
>
> Imo, having a standardized, versioned definition for GET, PUT, PUTALL,
> etc. message, that is encoded/decoded in a manner that multiple clients
> (written in many other languages) can encode/decode these messages, is
> paramount.
>
> Having the standardized operational messages(GET,PUT,etc.) transported
> using the function service vs a more direct operation handler, that is
> another discussion and is something that should be investigated.
>
> My immediate concerns regarding "normal" operations over the function
> service are:
>
>    1. I don't believe the current function service is "stream" enabled,
>    and would require some potential rework for subscription-based operations
>    2. Can the function service handle the extra load?
>    3. Is the function service "lean" enough to sustain acceptable
>    throughput? The current client/server protocol averages around
>    40,000-50,000 messages/second.
>    4. There are some messages that are passed between the client <->
>    locator. Given that the function service is "server" specific, this
>    approach would not work for locators, where a different transport mechanism
>    is required. (but this is not a show stopper if function service proves to
>    be viable)
>    5. How much effort would be required to make the "old" function
>    service, handle the new messages, ensuring that the current behavior is
>    preserved.
>
> As per a previous discussion we had, I believe that the "function-like"
> behavior (retry, HA, write vs read optimized) can incorporated into the
> processing layer on the server. In that way all messages can benefit from
> that behavior. In addition to this, if we have a single mechanism that will
> handle messages, retry, HA, read/write optimizations, is preferable to
> having a few "bespoke" implementations. So either approach (new message
> handling) vs function service, will be preferable.
>
> "*The advantage of this approach is that if someone just builds a driver
> that only supports function execution and whatever serialization framework
> is required to serialize function arguments, they already have an API that
> application developers could use to do pretty much anything they wanted to
> do on the server. Having a Region object with methods like get and put on
> it could just be a little syntatic sugar on top of that.*"
>
> It can be argued that having a standard client/server message, with
> standardized encoding/decoding, is the same as using function execution.
> Both require a little syntactic sugar to add new functionality to an
> already standardized message.
>
> --Udo
> On 5/1/17 17:27, Dan Smith wrote:
>
> I think any new client driver or server we develop might want to
> incorporate function execution at lower level than region operations like
> get and put, etc. We could then easily build operations like GET, PUT,
> PUTALL, etc. on top of that by making them functions. The original client
> protocol isn't designed like that because it pre-dates function execution.
>
> The current function execution API is a little clunky and needs some work.
> But what it does do is provide the fundamental logic to target operations
> at members that host certain keys and retry in the case of failure.
>
> The advantage of this approach is that if someone just builds a driver
> that only supports function execution and whatever 

[jira] [Created] (GEODE-2862) shutdown hook does not wait for disk store async tasks to complete

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2862:
---

 Summary: shutdown hook does not wait for disk store async tasks to 
complete
 Key: GEODE-2862
 URL: https://issues.apache.org/jira/browse/GEODE-2862
 Project: Geode
  Issue Type: Bug
  Components: persistence
Reporter: Darrel Schneider


If you do a normal cache close and are using persistence then each disk store 
close will wait for all of its async background tasks to complete.
But if instead the JVM shutdown hook is used (see 
java.lang.Runtime.addShutdownHook(Thread) for a description of what causes the 
shutdown hook to be called) then it will not wait for the async persistent 
tasks to complete.

Both of these types of shutdown are considered an orderly shutdown (as opposed 
to a unorderly shutdown caused by things like a kill -9) and geode should only 
have one type of orderly shutdown. By not waiting for the async persistent 
tasks to complete some files may never be fully written.

Here is the code that causes the shutdown hook to not wait in DiskStoreImpl:
{code}
  // don't block the shutdown hook
  if (Thread.currentThread() != InternalDistributedSystem.shutdownHook) {
waitForBackgroundTasks();
  }
{code}



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

Re: GEODE-2708: Upgrading Gradle Wrapper to 3.4.1

[Udo Kohlmeyer]

+1, so have I


On 5/2/17 11:09, Jared Stewart wrote:

+1 I've been running with Gradle 3+ without issues too


On May 2, 2017, at 11:04 AM, Anthony Baker  wrote:

+1 I’ve been running against gradle 3+ for awhile now.

Anthony


On May 2, 2017, at 10:55 AM, Mark Bretl  wrote:

I have done testing to upgrade our current Gradle wrapper version from
2.14.1 to 3.4.1. There are a couple of warnings during the build, however,
I didn't see anything in a precheckin run that would be an issue.

Anybody have any issues with updating Gradle before releasing 1.2.0?

If there no objections, I will checkin the upgrade changes on Thursday EOD
PST.

--Mark

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

[Dan Smith]

> IsPartialMessage: This flag gives us ability to send partial message
> without serializing the whole key-value(request). lets say I execute
> function at server and function just returns "arraylist of object". And the
> serialized size of ""arraylist of object"" is quite big( > 2gb).
>

My point about these fields is that it really seems like this stuff should
be handled by different layers. Ideally you would have a fragmentation
layer that is invisible to people writing specific messages, so that
messages are automatically fragmented if they get to large. Think about how
a TCP socket works - you just write data and it is automatically
fragmented. Or are you expecting each individual message type to have it's
own way to doing fragmentation, but it should set this header down in your
protocol layer? That seems really messy.

JSON: this is a feature we want to introduce, where client can send JSON
> string and we want to save that JSON string into pdx.


Same thing here, JSON support sounds great, but having a header field of
JSON_KEY seems like a hacky way to do that. It seems like that might belong
in your ValueHeader.




On Tue, May 2, 2017 at 10:20 AM, Udo Kohlmeyer 
wrote:

> Hey Dan,
>
> Imo, having a standardized, versioned definition for GET, PUT, PUTALL,
> etc. message, that is encoded/decoded in a manner that multiple clients
> (written in many other languages) can encode/decode these messages, is
> paramount.
>
> Having the standardized operational messages(GET,PUT,etc.) transported
> using the function service vs a more direct operation handler, that is
> another discussion and is something that should be investigated.
>
> My immediate concerns regarding "normal" operations over the function
> service are:
>
>1. I don't believe the current function service is "stream" enabled,
>and would require some potential rework for subscription-based operations
>2. Can the function service handle the extra load?
>3. Is the function service "lean" enough to sustain acceptable
>throughput? The current client/server protocol averages around
>40,000-50,000 messages/second.
>4. There are some messages that are passed between the client <->
>locator. Given that the function service is "server" specific, this
>approach would not work for locators, where a different transport mechanism
>is required. (but this is not a show stopper if function service proves to
>be viable)
>5. How much effort would be required to make the "old" function
>service, handle the new messages, ensuring that the current behavior is
>preserved.
>
> As per a previous discussion we had, I believe that the "function-like"
> behavior (retry, HA, write vs read optimized) can incorporated into the
> processing layer on the server. In that way all messages can benefit from
> that behavior. In addition to this, if we have a single mechanism that will
> handle messages, retry, HA, read/write optimizations, is preferable to
> having a few "bespoke" implementations. So either approach (new message
> handling) vs function service, will be preferable.
>
> "*The advantage of this approach is that if someone just builds a driver
> that only supports function execution and whatever serialization framework
> is required to serialize function arguments, they already have an API that
> application developers could use to do pretty much anything they wanted to
> do on the server. Having a Region object with methods like get and put on
> it could just be a little syntatic sugar on top of that.*"
>
> It can be argued that having a standard client/server message, with
> standardized encoding/decoding, is the same as using function execution.
> Both require a little syntactic sugar to add new functionality to an
> already standardized message.
>
> --Udo
> On 5/1/17 17:27, Dan Smith wrote:
>
> I think any new client driver or server we develop might want to
> incorporate function execution at lower level than region operations like
> get and put, etc. We could then easily build operations like GET, PUT,
> PUTALL, etc. on top of that by making them functions. The original client
> protocol isn't designed like that because it pre-dates function execution.
>
> The current function execution API is a little clunky and needs some work.
> But what it does do is provide the fundamental logic to target operations
> at members that host certain keys and retry in the case of failure.
>
> The advantage of this approach is that if someone just builds a driver
> that only supports function execution and whatever serialization framework
> is required to serialize function arguments, they already have an API that
> application developers could use to do pretty much anything they wanted to
> do on the server. Having a Region object with methods like get and put on
> it could just be a little syntatic sugar on top of that.
>
> -Dan
>
> On Fri, Apr 28, 2017 at 2:49 PM, Udo Kohlmeyer 

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

[Jared Stewart]

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




geode-core/src/main/java/org/apache/geode/cache/execute/internal/FunctionServiceManager.java
Line 429 (original), 441 (patched)


It looks like for each group, there is an unnecessary copy happening on 441 
and a shuffle of the full collection on 446 just to grab a single random 
element.  What do you think about this instead?

```
Set grpMembers = system.getGroupMembers(group);
  if (!grpMembers.isEmpty()) {
if (!RANDOM_onMember && 
grpMembers.contains(system.getDistributedMember())) {
  members.add(system.getDistributedMember());
} else {
  int randomIndex = RandomUtils.nextInt(grpMembers.size());
  DistributedMember randomMember = 
grpMembers.stream().skip(randomIndex).findFirst().get();
  members.add(randomMember);
}
  }
```


- Jared Stewart


On May 2, 2017, 12:06 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 2, 2017, 12:06 a.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
> -
> 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/common/CacheProperty.java
>  fe16fc3bd85e5861205dcdac6583d32abe57fcac 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/filter/GemfireSessionManager.java
>  20cfecac2aaafd09c04eb6115a0da9c99201927b 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
>  edc2b7d8bfc684257c27d90d4b8d0c4db378347d 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/util/CreateRegionFunction.java
>  4e9e9fdf63eba622a157138e8e164956c257f093 
>   
> 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 
>   
> 

[jira] [Created] (GEODE-2861) remove deadcode in GemFireCacheImpl and DiskStoreImpl for DiskStoreTaskPool

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2861:
---

 Summary: remove deadcode in GemFireCacheImpl and DiskStoreImpl for 
DiskStoreTaskPool
 Key: GEODE-2861
 URL: https://issues.apache.org/jira/browse/GEODE-2861
 Project: Geode
  Issue Type: Improvement
  Components: persistence
Reporter: Darrel Schneider


Both GemFireCacheImpl and DiskStoreImpl have deadcode related to shutting down 
the DiskStoreTaskPool.

On DiskStoreImpl see these methods:
  stopDiskStoreTaskPool
  shutdownPool
On GemFireCacheImpl the field diskStoreTaskPool is always null.

Note that a bug exists in this deadcode that causes it to not call 
taskCancelled as it iterates over a list of runnables. Since this code is dead 
it is currently doing no harm but if the code is not removed then make sure and 
fix this loop.



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

[jira] [Updated] (GEODE-2861) remove deadcode in GemFireCacheImpl and DiskStoreImpl for DiskStoreTaskPool

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-2861:

Priority: Trivial  (was: Major)

> remove deadcode in GemFireCacheImpl and DiskStoreImpl for DiskStoreTaskPool
> ---
>
> Key: GEODE-2861
> URL: https://issues.apache.org/jira/browse/GEODE-2861
> Project: Geode
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Darrel Schneider
>Priority: Trivial
>
> Both GemFireCacheImpl and DiskStoreImpl have deadcode related to shutting 
> down the DiskStoreTaskPool.
> On DiskStoreImpl see these methods:
>   stopDiskStoreTaskPool
>   shutdownPool
> On GemFireCacheImpl the field diskStoreTaskPool is always null.
> Note that a bug exists in this deadcode that causes it to not call 
> taskCancelled as it iterates over a list of runnables. Since this code is 
> dead it is currently doing no harm but if the code is not removed then make 
> sure and fix this loop.



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

[GitHub] geode pull request #487: geode-2848: when found all the partitioned region i...

[gesterzhou]

GitHub user gesterzhou opened a pull request:

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

geode-2848: when found all the partitioned region is destroyed, add b…

@upthewaterspout @boglesby 

Need to check if shadow PR is destroyed and add back the events that are 
not put into queueRemoveAllMesg. 

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

$ git pull https://github.com/apache/geode feature/GEM-1353

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

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


commit 08ba1244d6c19f0a753a520f18400f9747093885
Author: zhouxh 
Date:   2017-05-01T21:41:22Z

geode-2848: when found all the partitioned region is destroyed, add back the
events




---
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-2860) refactor EventTracker to be on DistributedRegion instead of LocalRegion

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2860:
---

 Summary: refactor EventTracker to be on DistributedRegion instead 
of LocalRegion
 Key: GEODE-2860
 URL: https://issues.apache.org/jira/browse/GEODE-2860
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Darrel Schneider


Currently LocalRegion has a non-final field named "eventTracker". It is 
initialized in a method named createEventTracker which does nothing on 
LocalRegion but is implemented on DistributedRegion and BucketRegion to 
initialize the eventTracker field.

I think things would be clearer if this field was moved to DistributedRegion.
All the code on LocalRegion that currently tests for a non-null eventTracker 
can be changed to do nothing and overridden on DistributedRegion to use its 
eventTracker. DistributedRegion can make this field final and always set it in 
its constructor. Since BucketRegion extends DistributedRegion it does not to do 
anything (it currently implements createEventTracker but that was not needed 
since it inherits the same impl from DistributedRegion).




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

Re: GEODE-2708: Upgrading Gradle Wrapper to 3.4.1

[Anthony Baker]

+1 I’ve been running against gradle 3+ for awhile now.

Anthony

> On May 2, 2017, at 10:55 AM, Mark Bretl  wrote:
> 
> I have done testing to upgrade our current Gradle wrapper version from
> 2.14.1 to 3.4.1. There are a couple of warnings during the build, however,
> I didn't see anything in a precheckin run that would be an issue.
> 
> Anybody have any issues with updating Gradle before releasing 1.2.0?
> 
> If there no objections, I will checkin the upgrade changes on Thursday EOD
> PST.
> 
> --Mark

Re: Remove keys from a PartitionedRegion

[Goutam Tadi]

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

[jira] [Updated] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan updated GEODE-2859:

Description: 
https://builds.apache.org/job/Geode-nightly/821/

This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was 
recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). 
Probably it needs the same fix or related.

ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run.

  was:
https://builds.apache.org/job/Geode-nightly/821/

This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was 
recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). 
Probably it needs the same fix or related.


> ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
> 
>
> Key: GEODE-2859
> URL: https://issues.apache.org/jira/browse/GEODE-2859
> Project: Geode
>  Issue Type: Test
>  Components: membership, messaging, tests
>Reporter: Galen O'Sullivan
> Fix For: 1.2.0
>
>
> https://builds.apache.org/job/Geode-nightly/821/
> This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was 
> recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). 
> Probably it needs the same fix or related.
> ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run.



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

[jira] [Resolved] (GEODE-2816) Redundancy recovery must also kick in when redundancy recovery is set to 0

[nabarun (JIRA)]

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

nabarun resolved GEODE-2816.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Redundancy recovery must also kick in when redundancy recovery is set to 0 
> ---
>
> Key: GEODE-2816
> URL: https://issues.apache.org/jira/browse/GEODE-2816
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> Issue:
> In methods {noformat}scheduleRedundancyRecovery{noformat} and 
> {noformat}initPRInternals{noformat} redundancy recovery is initiated only 
> when redundancy is set to a value greater than zero.
> This leads to issues where a bucket is hosted in multiple datastores when the 
> redundancy is set to 0 as redundancy recovery never removes the extra buckets.
> Solution:
> remove the checks where the redundancy recovery is initiated only when the 
> redundancy is set to a value greater than 0.



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

[jira] [Assigned] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan reassigned GEODE-2859:
---

Assignee: Galen O'Sullivan

> ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
> 
>
> Key: GEODE-2859
> URL: https://issues.apache.org/jira/browse/GEODE-2859
> Project: Geode
>  Issue Type: Test
>  Components: membership, messaging, tests
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
> Fix For: 1.2.0
>
>
> https://builds.apache.org/job/Geode-nightly/821/
> This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was 
> recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). 
> Probably it needs the same fix or related.
> ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run.



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

[jira] [Commented] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan commented on GEODE-2859:
-

related failing tests.

> ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
> 
>
> Key: GEODE-2859
> URL: https://issues.apache.org/jira/browse/GEODE-2859
> Project: Geode
>  Issue Type: Test
>  Components: membership, messaging, tests
>Reporter: Galen O'Sullivan
> Fix For: 1.2.0
>
>
> https://builds.apache.org/job/Geode-nightly/821/
> This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was 
> recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). 
> Probably it needs the same fix or related.



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

[jira] [Created] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.

[Galen O'Sullivan (JIRA)]

Galen O'Sullivan created GEODE-2859:
---

 Summary: ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction 
failing in CI.
 Key: GEODE-2859
 URL: https://issues.apache.org/jira/browse/GEODE-2859
 Project: Geode
  Issue Type: Test
  Components: membership, messaging, tests
Reporter: Galen O'Sullivan
 Fix For: 1.2.0


https://builds.apache.org/job/Geode-nightly/821/

This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was 
recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). 
Probably it needs the same fix or related.



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

GEODE-2708: Upgrading Gradle Wrapper to 3.4.1

[Mark Bretl]

I have done testing to upgrade our current Gradle wrapper version from
2.14.1 to 3.4.1. There are a couple of warnings during the build, however,
I didn't see anything in a precheckin run that would be an issue.

Anybody have any issues with updating Gradle before releasing 1.2.0?

If there no objections, I will checkin the upgrade changes on Thursday EOD
PST.

--Mark

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

[Ken Howe]

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



Posting my review of the next chunk of files


geode-core/src/main/java/org/apache/geode/cache/client/ClientCacheFactory.java
Line 227 (original), 232 (patched)


Can be clarified using StringUtils.isEmpty(propvalue)



geode-core/src/main/java/org/apache/geode/cache/client/internal/PoolImpl.java
Line 222 (original), 242 (patched)


Can use StringUtils.isEmpty(serverGroup).



geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledIn.java
Line 184 (original), 177 (patched)


remove 'this.'



geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledLike.java
Line 39 (original), 37 (patched)


Does logger need to be static?



geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledLike.java
Lines 39-62 (original), 37-62 (patched)


As a matter of form, I would group the statics together (single spaced) and 
then the instance variables (also single spaced).



geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
Line 1503 (original), 1409 (patched)


For consistency, suggest renaming this method to 
getConditionedRelationshipIndexResultsExpandedToTopOrCGJLevel

(similar to the renamed getConditionedIndexResults)


- Ken Howe


On May 2, 2017, 12:06 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 2, 2017, 12:06 a.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
> -
> 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/common/CacheProperty.java
>  fe16fc3bd85e5861205dcdac6583d32abe57fcac 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/filter/GemfireSessionManager.java
>  20cfecac2aaafd09c04eb6115a0da9c99201927b 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
>  edc2b7d8bfc684257c27d90d4b8d0c4db378347d 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/util/CreateRegionFunction.java
>  4e9e9fdf63eba622a157138e8e164956c257f093 
>   
> 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 
> 

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

[Jared Stewart]

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




extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
Line 301 (original), 310 (patched)


Is there a compelling reason to use 
`Context.class.isInstance(this.container)` vs `this.container instanceof 
Context`?  I wasn't too familar with `Class#isInstance`, but StackOverflow 
seemed to sugget that `instanceof` is preferred when sufficient:

http://stackoverflow.com/a/8692245/3988499



extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
Line 507 (original), 520 (patched)


I believe this performs an uncessary copy of the set of sessionIds.  The 
following would seem to do the same thing more efficiently: 

```
Set sessionIds = this.sessionsToTouch;
this.sessionsToTouch = new HashSet<>();
```



extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
Lines 935 (patched)


This method can be replaced with calls to 
`org.apache.geode.internal.util.IOUtils#close`.


- Jared Stewart


On May 2, 2017, 12:06 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 2, 2017, 12:06 a.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
> -
> 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/common/CacheProperty.java
>  fe16fc3bd85e5861205dcdac6583d32abe57fcac 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/filter/GemfireSessionManager.java
>  20cfecac2aaafd09c04eb6115a0da9c99201927b 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
>  edc2b7d8bfc684257c27d90d4b8d0c4db378347d 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/util/CreateRegionFunction.java
>  4e9e9fdf63eba622a157138e8e164956c257f093 
>   
> 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 
>   

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

[Udo Kohlmeyer]

Hey Dan,

Imo, having a standardized, versioned definition for GET, PUT, PUTALL, 
etc. message, that is encoded/decoded in a manner that multiple clients 
(written in many other languages) can encode/decode these messages, is 
paramount.


Having the standardized operational messages(GET,PUT,etc.) transported 
using the function service vs a more direct operation handler, that is 
another discussion and is something that should be investigated.


My immediate concerns regarding "normal" operations over the function 
service are:


1. I don't believe the current function service is "stream" enabled,
   and would require some potential rework for subscription-based
   operations
2. Can the function service handle the extra load?
3. Is the function service "lean" enough to sustain acceptable
   throughput? The current client/server protocol averages around
   40,000-50,000 messages/second.
4. There are some messages that are passed between the client <->
   locator. Given that the function service is "server" specific, this
   approach would not work for locators, where a different transport
   mechanism is required. (but this is not a show stopper if function
   service proves to be viable)
5. How much effort would be required to make the "old" function
   service, handle the new messages, ensuring that the current behavior
   is preserved.

As per a previous discussion we had, I believe that the "function-like" 
behavior (retry, HA, write vs read optimized) can incorporated into the 
processing layer on the server. In that way all messages can benefit 
from that behavior. In addition to this, if we have a single mechanism 
that will handle messages, retry, HA, read/write optimizations, is 
preferable to having a few "bespoke" implementations. So either approach 
(new message handling) vs function service, will be preferable.


"/The advantage of this approach is that if someone just builds a driver 
that only supports function execution and whatever serialization 
framework is required to serialize function arguments, they already have 
an API that application developers could use to do pretty much anything 
they wanted to do on the server. Having a Region object with methods 
like get and put on it could just be a little syntatic sugar on top of 
that./"


It can be argued that having a standard client/server message, with 
standardized encoding/decoding, is the same as using function execution. 
Both require a little syntactic sugar to add new functionality to an 
already standardized message.


--Udo

On 5/1/17 17:27, Dan Smith wrote:
I think any new client driver or server we develop might want to 
incorporate function execution at lower level than region operations 
like get and put, etc. We could then easily build operations like GET, 
PUT, PUTALL, etc. on top of that by making them functions. The 
original client protocol isn't designed like that because it pre-dates 
function execution.


The current function execution API is a little clunky and needs some 
work. But what it does do is provide the fundamental logic to target 
operations at members that host certain keys and retry in the case of 
failure.


The advantage of this approach is that if someone just builds a driver 
that only supports function execution and whatever serialization 
framework is required to serialize function arguments, they already 
have an API that application developers could use to do pretty much 
anything they wanted to do on the server. Having a Region object with 
methods like get and put on it could just be a little syntatic sugar 
on top of that.


-Dan

On Fri, Apr 28, 2017 at 2:49 PM, Udo Kohlmeyer > wrote:


Hi there Geode community,

The new Client-Server protocol proposal is available for review.

It can be viewed and commented on
https://cwiki.apache.org/confluence/display/GEODE/New+Client+Server+Protocol



--Udo

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

[Anthony Baker]

I think the downside of having a single generic message type is that we lose 
“type safety” and some efficiency.  The message definition would essentially 
become:

String functionName;
byte[][] args;

It’s a little more challenging for an author of a Geode Driver to fill in the 
args correctly compared to calling specific methods on a generated stub.  Also, 
if the argument data types are fixed in the message definition we can apply 
efficient encoding techniques automatically (e.g. varint, zigzag, optional).

I also wonder about the code path efficiency for functions vs get / put.  That 
would be an interesting test.


Anthony

> On May 1, 2017, at 5:27 PM, Dan Smith  wrote:
> 
> I think any new client driver or server we develop might want to
> incorporate function execution at lower level than region operations like
> get and put, etc. We could then easily build operations like GET, PUT,
> PUTALL, etc. on top of that by making them functions. The original client
> protocol isn't designed like that because it pre-dates function execution.
> 
> The current function execution API is a little clunky and needs some work.
> But what it does do is provide the fundamental logic to target operations
> at members that host certain keys and retry in the case of failure.
> 
> The advantage of this approach is that if someone just builds a driver that
> only supports function execution and whatever serialization framework is
> required to serialize function arguments, they already have an API that
> application developers could use to do pretty much anything they wanted to
> do on the server. Having a Region object with methods like get and put on
> it could just be a little syntatic sugar on top of that.
> 
> -Dan
> 
> On Fri, Apr 28, 2017 at 2:49 PM, Udo Kohlmeyer 
> wrote:
> 
>> Hi there Geode community,
>> 
>> The new Client-Server protocol proposal is available for review.
>> 
>> It can be viewed and commented on https://cwiki.apache.org/confl
>> uence/display/GEODE/New+Client+Server+Protocol
>> 
>> --Udo
>> 
>> 

Re: Review Request 58891: GEODE-2837: Start server creates specified working dir if necessary

[Jared Stewart]

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

(Updated May 2, 2017, 4:03 p.m.)


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


Repository: geode


Description
---

GEODE-2837: Start server creates specified working dir if necessary


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsIntegrationTest.java
 b51505a 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
 0e681d7 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 a793235 


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


Testing (updated)
---

Precheckin passed


Thanks,

Jared Stewart

[jira] [Commented] (GEODE-2846) IndexMaintenanceException while PDX ClientTypeRegistration.defineType if using 2 pools by client cache

[Roman Ovechkin (JIRA)]

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

Roman Ovechkin commented on GEODE-2846:
---

The main question is Why newly defined type is sent to only ONE pool and not to 
ALL
in here:
ClientTypeRegistration.defineType(PdxType) line: 61 

> IndexMaintenanceException while PDX ClientTypeRegistration.defineType if 
> using 2 pools by client cache
> --
>
> Key: GEODE-2846
> URL: https://issues.apache.org/jira/browse/GEODE-2846
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Roman Ovechkin
>
> Client has configuration with 2 regions  and  2 Pools - /region1 in pool1, 
> /region2 in pool2 (two different distributed systems), using 
> PdxAutoSerializer, Want to put Object1 to /region1 and Object2 to /region2. 
> During put operation at first, AutoSerialiser generates new PDX type for 
> Object1, and sending this type to ONLY one pool (and wrong one) it sends type 
> to arbitrary first available pool which in my case is pool2, 
> after that it's trying to put value to /region1 which is in pool 1 and 
> because /region1 has indexes it cause IndexMaintenanceException: unknown pdx 
> type.
> I guess pdx types must be sent to all pools while defining.
> Here is full stack trace where issue happening:
>   ClientTypeRegistration.defineType(PdxType) line: 61 
>   TypeRegistry.defineType(PdxType) line: 195  
>   TypeRegistry.defineLocalType(Object, PdxType) line: 234 
>   PdxWriterImpl.completeByteStreamGeneration() line: 481  
>   PdxWriterImpl.getAutoPdxType() line: 510
>   AutoSerializableManager.writeData(PdxWriter, Object, 
> AutoSerializableManager$AutoClassInfo) line: 1891  
>   AutoSerializableManager.writeData(PdxWriter, Object) line: 1829 
>   ReflectionBasedAutoSerializer.toData(Object, PdxWriter) line: 316   
>   InternalDataSerializer.writePdx(DataOutput, GemFireCacheImpl, Object, 
> PdxSerializer) line: 3106 
>   InternalDataSerializer.writeUserObject(Object, DataOutput, boolean) 
> line: 1587  
>   InternalDataSerializer.writeWellKnownObject(Object, DataOutput, 
> boolean) line: 1482 
>   InternalDataSerializer.basicWriteObject(Object, DataOutput, boolean) 
> line: 2188 
>   DataSerializer.writeObject(Object, DataOutput) line: 2871   
>   BlobHelper.serializeTo(Object, HeapDataOutputStream) line: 66   
>   Message.serializeAndAddPart(Object, boolean) line: 395  
>   Message.addObjPart(Object, boolean) line: 344   
>   Message.addObjPart(Object) line: 324
>   PutOp$PutOpImpl.(Region, Object, Object, byte[], EntryEventImpl, 
> Operation, boolean, Object, Object, boolean, boolean) line: 304  
>   PutOp.execute(ExecutablePool, LocalRegion, Object, Object, byte[], 
> EntryEventImpl, Operation, boolean, Object, Object, boolean) line: 73
>   ServerRegionProxy.put(Object, Object, byte[], EntryEventImpl, 
> Operation, boolean, Object, Object, boolean) line: 175
>   LocalRegion.serverPut(EntryEventImpl, boolean, Object) line: 3173   
>   LocalRegion.cacheWriteBeforePut(EntryEventImpl, Set, CacheWriter, 
> boolean, Object) line: 3300   
>   ProxyRegionMap.basicPut(EntryEventImpl, long, boolean, boolean, Object, 
> boolean, boolean) line: 231 
>   LocalRegion.virtualPut(EntryEventImpl, boolean, boolean, Object, 
> boolean, long, boolean) line: 5955 
>   LocalRegionDataView.putEntry(EntryEventImpl, boolean, boolean, Object, 
> boolean, long, boolean) line: 132
>   LocalRegion.basicPut(EntryEventImpl, boolean, boolean, Object, boolean) 
> line: 5350  
>   LocalRegion.validatedPut(EntryEventImpl, long) line: 1668   
>   LocalRegion.put(Object, Object, Object) line: 1655  
>   LocalRegion(AbstractRegion).put(Object, Object) line: 288   
> ...



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

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

[Oleg (JIRA)]

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

Oleg updated GEODE-2858:

Description: 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.  (was: 
Geode 1.0 had a regression where it could not load config xml file with pool or 
locator configuration in it.  It was fixed in 1.1 but no test was added.  Add a 
unit test to prevent this coming back.)

> 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
>
> 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] [Updated] (GEODE-2858) Add test to verify successful load of configuration with pool or locator

[Oleg (JIRA)]

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

Oleg updated GEODE-2858:

Priority: Minor  (was: Major)

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

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

[Ken Howe]

> On May 1, 2017, 10:28 p.m., Ken Howe wrote:
> > geode-core/src/main/java/org/apache/geode/cache/AttributesFactory.java
> > Line 237 (original), 232 (patched)
> > 
> >
> > {@code byteThreshold  should be
> > {@code byteThreshold}
> 
> Kirk Lund wrote:
> Yeah, looks like  was ignored because I had "Match Case" checked 
> when I replaced  with }
> 
> I haven't found any others yet. What classes have these typos in them?

The other places I was referring to are the extra lines in DynamicRegionFactory 
where you ended up with "code" inside of the \...\ tags


- Ken


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


On May 2, 2017, 12:06 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 2, 2017, 12:06 a.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
> -
> 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/common/CacheProperty.java
>  fe16fc3bd85e5861205dcdac6583d32abe57fcac 
>   
> extensions/geode-modules-session-internal/src/main/java/org/apache/geode/modules/session/internal/filter/GemfireSessionManager.java
>  20cfecac2aaafd09c04eb6115a0da9c99201927b 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/DeltaSessionManager.java
>  edc2b7d8bfc684257c27d90d4b8d0c4db378347d 
>   
> extensions/geode-modules/src/main/java/org/apache/geode/modules/util/CreateRegionFunction.java
>  4e9e9fdf63eba622a157138e8e164956c257f093 
>   
> 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 
>   
> 

[GitHub] geode issue #397: GEODE-2858 - Add junit to try parsing of simple XML file w...

[oshvarts]

Github user oshvarts commented on the issue:

https://github.com/apache/geode/pull/397
  
Jira issue added; pull request renamed.


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