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

[Avinash Dongre (JIRA)]

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

Avinash Dongre resolved GEODE-237.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-237:
--

Github user asfgit closed the pull request at:

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


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



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

[GitHub] geode pull request #496: GEODE-237: Removed deprecated API from EntryEvent

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-254) Remove deprecated Region.keys and Region.entries

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-254:
---

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

GEODE-254: Addressing review comments from PR #488 Replacing all inststance of 
entries with entrySet

GEODE-254: Fixing the Test Failures
 - Removed test testIndexMaintenanceWithIndexOnMethodEntries since this is no 
more applicable.

GEODE-254: Spotless fixing.
This closes #504

Signed-off-by: adongre 


> 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
> Fix For: 1.2.0
>
>   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 subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-254:
---

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

GEODE-254: Addressing review comments from PR #488 Replacing all inststance of 
entries with entrySet

GEODE-254: Fixing the Test Failures
 - Removed test testIndexMaintenanceWithIndexOnMethodEntries since this is no 
more applicable.

GEODE-254: Spotless fixing.
This closes #504

Signed-off-by: adongre 


> 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
> Fix For: 1.2.0
>
>   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=16007491#comment-16007491
 ] 

ASF GitHub Bot commented on GEODE-254:
--

Github user asfgit closed the pull request at:

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


> 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
> Fix For: 1.2.0
>
>   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 subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-254:
---

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

GEODE-254: Addressing review comments from PR #488 Replacing all inststance of 
entries with entrySet

GEODE-254: Fixing the Test Failures
 - Removed test testIndexMaintenanceWithIndexOnMethodEntries since this is no 
more applicable.

GEODE-254: Spotless fixing.
This closes #504

Signed-off-by: adongre 


> 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
> Fix For: 1.2.0
>
>   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 #504: GEODE-254: Removed deprecated Region.keys and Regio...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: Finer grained security

[Swapnil Bawaskar]

Thanks for feedback! I have tried to incorporate this on our wiki:
https://cwiki.apache.org/confluence/display/GEODE/Finer+grained+security.
Comments welcome.

On Thu, Apr 27, 2017 at 1:33 PM John Blum  wrote:

> +1 to Jake's comments, and is a fundamental property of Java's security
> internally.
>
> On Thu, Apr 27, 2017 at 1:09 PM, Jacob Barrett 
> wrote:
>
> > Typical solution to the X service needs to create something it service Y
> > where user has permission to X but not to Y is to treat the actions on Y
> > performed by X to be trusted. Often I have seen this implemented such
> that
> > after asserting permission on "create" on X that X performs actions on Y
> as
> > a trusted principal, like a "SYSTEM" user. The other option is to give
> each
> > service a trusted account and elevate to "SERVICE-X" where Y would allow
> > "SERVICE-X" to perform some set of operations.
> >
> > See
> > https://docs.oracle.com/javase/7/docs/api/javax/
> > security/auth/Subject.html#doAs(javax.security.auth.
> > Subject,%20java.security.PrivilegedAction
> > )
> >
> > -Jake
> >
> >
> > On Thu, Apr 27, 2017 at 11:28 AM Michael Stolz 
> wrote:
> >
> > > We have seen users who need per-Region permission for Data read/write,
> so
> > > there is precedent there at least.
> > >
> > > --
> > > Mike Stolz
> > > Principal Engineer, GemFire Product Manager
> > > Mobile: +1-631-835-4771 <(631)%20835-4771> <(631)%20835-4771>
> > >
> > > On Thu, Apr 27, 2017 at 2:11 PM, pulkit chandra <
> > pulkit.chan...@gmail.com>
> > > wrote:
> > >
> > > > For per instance permission, I would say look for the evidence. Do we
> > > have
> > > > evidence that customers want per instance permission? If not may be
> > > > implement minimally in the first cut and validate with customers if
> > they
> > > > want per instance model?
> > > >
> > > > About Lucene concern, It is in fact good to provide permission for
> per
> > > > logical operation that implementation is doing. This will align the
> > > > security permission with operations performed and provide better
> design
> > > of
> > > > a role. I would argue if you are able to perform 2 logically separate
> > > > operations with single permission is perhaps a smell that you might
> not
> > > > have enough permissions.
> > > >
> > > > my $0.02
> > > >
> > > > On Wed, 26 Apr 2017 at 16:54 Dan Smith  wrote:
> > > >
> > > > > I agree that async event queues seem like a different case than wan
> > or
> > > > > disk. In that case you are not using anything that creating a
> region
> > > > > doesn't do.
> > > > >
> > > > > Shouldn't creating a region be DATA:MANAGE:DISK? Requiring DATA
> > > > privileges
> > > > > for a region without disk and CLUSTER privileges for a region with
> > disk
> > > > > seems weird. Same issues with creating a region that uses WAN.
> > > > >
> > > > > -Dan
> > > > >
> > > > > On Wed, Apr 26, 2017 at 12:53 PM, Diane Rose Hardman <
> > > > dhard...@pivotal.io>
> > > > > wrote:
> > > > >
> > > > > > One more possible complication is that creating a Lucene index
> will
> > > > also
> > > > > > create an AsyncEventQueue. Today the required permission to
> create
> > > the
> > > > > AEQ
> > > > > > is DATA:MANAGE which coincidentally nicely matches the permission
> > > > > required
> > > > > > to create an OQL index.
> > > > > > Pulling out the AEQ as a separate resource will affect Lucene
> index
> > > > > > creation. FYI.
> > > > > >
> > > > > > On Tue, Apr 25, 2017 at 3:10 PM, Jinmei Liao 
> > > > wrote:
> > > > > >
> > > > > > > DATA:*:RegionA would allow you to only operate that region but
> > not
> > > > all
> > > > > of
> > > > > > > them.
> > > > > > >
> > > > > > > if we want to control a specific wan, maybe we add a fourth
> > > > parameter:
> > > > > > > cluster:*:wan:wanName, same goes for Disk etc.
> > > > > > >
> > > > > > > On Tue, Apr 25, 2017 at 3:03 PM, Jacob Barrett <
> > > jbarr...@pivotal.io>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Think further, what about the team that ask that I be able to
> > > > mange a
> > > > > > > > region not all regions, or a wan not all wan. It may be time
> to
> > > > think
> > > > > > > about
> > > > > > > > a full per instance /
> > > > > > > > named resource based security model.
> > > > > > > >
> > > > > > > > On Tue, Apr 25, 2017 at 2:59 PM Jared Stewart <
> > > jstew...@pivotal.io
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > +1
> > > > > > > > >
> > > > > > > > > I think it would also be a good idea to move the current
> > > > operations
> > > > > > > > > permitted by CLUSTER:MANAGE ( stop server, alter runtime,
> > etc)
> > > to
> > > > > > > require
> > > > > > > > > the more specific CLUSTER:MANAGE:MEMBER in order to avoid
> > > > > ambiguity.
> > > > > > > > (This
> > > > > > > > > is not a breaking change since CLUSTER:MANAGE implies
> > > > > > > > > CLUSTER:MANAGE:MEMBER.)
> > > > > > > > >
> > 

[jira] [Resolved] (GEODE-2812) Add API to get list of live locators

[Masaki Yamakawa (JIRA)]

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

Masaki Yamakawa resolved GEODE-2812.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Add API to get list of live locators
> 
>
> Key: GEODE-2812
> URL: https://issues.apache.org/jira/browse/GEODE-2812
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
> Fix For: 1.2.0
>
>
> There is a Geode cluster using a logical member group, and from the client, 
> the connection pool to the logical member group is connected using the 
> PoolFactory API at the timing when connection becomes necessary.
> At this time, even though the locator that was running at the initial 
> connection stops due to reasons such as regular maintenance etc., even if the 
> alternate locator is started before maintenance, I can not connect to the 
> locator in the static initial list.
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupA").create("pool1");
> # Geode cluster:start locator [ localhost:10335 ].
> # Geode cluster:stop locator [ localhost:10334 ].
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupB").create("pool2");
> Therefore, I would like to decide the connection destination based on the 
> live locator list of another logical member group.
> I added an API that can get the list of live locators from the Pool. Use the 
> API as follows:
> {code:java|borderStyle=solid}
> Pool pool = PoolManager.createFactory()
>   .addLocator("localhost", 10334)
>   .setSubscriptionEnabled(true).setServerGroup("GroupA")
>   .create("GroupAPool");
> List = pool.getLiveLocators();
> {code}
> {quote}
> Note:
> The list of live locators gets the result of the UpdateLocatorListTask 
> periodically running in AutoConnectionSourceImpl.
> Therefore, whether or not it is alive will cause a time lag, depending on the 
> task execution interval.
> Also, the result of ExplicitConnectionSourceImpl without using a locator is 
> always empty.
> {quote}



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

[jira] [Commented] (GEODE-2812) Add API to get list of live locators

[ASF GitHub Bot (JIRA)]

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

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

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/475
  
PR Closing, merged to "develop" branch.


> Add API to get list of live locators
> 
>
> Key: GEODE-2812
> URL: https://issues.apache.org/jira/browse/GEODE-2812
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> There is a Geode cluster using a logical member group, and from the client, 
> the connection pool to the logical member group is connected using the 
> PoolFactory API at the timing when connection becomes necessary.
> At this time, even though the locator that was running at the initial 
> connection stops due to reasons such as regular maintenance etc., even if the 
> alternate locator is started before maintenance, I can not connect to the 
> locator in the static initial list.
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupA").create("pool1");
> # Geode cluster:start locator [ localhost:10335 ].
> # Geode cluster:stop locator [ localhost:10334 ].
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupB").create("pool2");
> Therefore, I would like to decide the connection destination based on the 
> live locator list of another logical member group.
> I added an API that can get the list of live locators from the Pool. Use the 
> API as follows:
> {code:java|borderStyle=solid}
> Pool pool = PoolManager.createFactory()
>   .addLocator("localhost", 10334)
>   .setSubscriptionEnabled(true).setServerGroup("GroupA")
>   .create("GroupAPool");
> List = pool.getLiveLocators();
> {code}
> {quote}
> Note:
> The list of live locators gets the result of the UpdateLocatorListTask 
> periodically running in AutoConnectionSourceImpl.
> Therefore, whether or not it is alive will cause a time lag, depending on the 
> task execution interval.
> Also, the result of ExplicitConnectionSourceImpl without using a locator is 
> always empty.
> {quote}



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

[jira] [Commented] (GEODE-2812) Add API to get list of live locators

[ASF GitHub Bot (JIRA)]

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

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

Github user masaki-yamakawa closed the pull request at:

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


> Add API to get list of live locators
> 
>
> Key: GEODE-2812
> URL: https://issues.apache.org/jira/browse/GEODE-2812
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> There is a Geode cluster using a logical member group, and from the client, 
> the connection pool to the logical member group is connected using the 
> PoolFactory API at the timing when connection becomes necessary.
> At this time, even though the locator that was running at the initial 
> connection stops due to reasons such as regular maintenance etc., even if the 
> alternate locator is started before maintenance, I can not connect to the 
> locator in the static initial list.
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupA").create("pool1");
> # Geode cluster:start locator [ localhost:10335 ].
> # Geode cluster:stop locator [ localhost:10334 ].
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupB").create("pool2");
> Therefore, I would like to decide the connection destination based on the 
> live locator list of another logical member group.
> I added an API that can get the list of live locators from the Pool. Use the 
> API as follows:
> {code:java|borderStyle=solid}
> Pool pool = PoolManager.createFactory()
>   .addLocator("localhost", 10334)
>   .setSubscriptionEnabled(true).setServerGroup("GroupA")
>   .create("GroupAPool");
> List = pool.getLiveLocators();
> {code}
> {quote}
> Note:
> The list of live locators gets the result of the UpdateLocatorListTask 
> periodically running in AutoConnectionSourceImpl.
> Therefore, whether or not it is alive will cause a time lag, depending on the 
> task execution interval.
> Also, the result of ExplicitConnectionSourceImpl without using a locator is 
> always empty.
> {quote}



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

[GitHub] geode issue #475: GEODE-2812: Add API to get list of live locators

[masaki-yamakawa]

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/475
  
PR Closing, merged to "develop" branch.


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

[GitHub] geode pull request #475: GEODE-2812: Add API to get list of live locators

[masaki-yamakawa]

Github user masaki-yamakawa closed the pull request at:

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


---
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 59206: GEODE-2836: CacheLoader now extends Declarable

[Darrel Schneider]

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


Ship it!




Ship It!

- Darrel Schneider


On May 11, 2017, 2:45 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59206/
> ---
> 
> (Updated May 11, 2017, 2:45 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2836: CacheLoader now extends Declarable
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/cache/CacheCallback.java a272afb 
>   geode-core/src/main/java/org/apache/geode/cache/Declarable.java 57e1e63 
> 
> 
> Diff: https://reviews.apache.org/r/59206/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 59206: GEODE-2836: CacheLoader now extends Declarable

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On May 11, 2017, 9:45 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59206/
> ---
> 
> (Updated May 11, 2017, 9:45 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2836: CacheLoader now extends Declarable
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/cache/CacheCallback.java a272afb 
>   geode-core/src/main/java/org/apache/geode/cache/Declarable.java 57e1e63 
> 
> 
> Diff: https://reviews.apache.org/r/59206/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[jira] [Commented] (GEODE-2876) CI Failure: org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest#testMultipleGfshClientToOneServer

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2876:


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

GEODE-2876: add logging and testing to diagnose test failure


> CI Failure: 
> org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest#testMultipleGfshClientToOneServer
> -
>
> Key: GEODE-2876
> URL: https://issues.apache.org/jira/browse/GEODE-2876
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Jared Stewart
>
> ConcurrentDeployDUnitTest is failing due to a parsing error.
> {noformat}
> Error
> java.lang.AssertionError: An exception occurred during asynchronous 
> invocation.
> Stacktrace
> java.lang.AssertionError: An exception occurred during asynchronous 
> invocation.
>   at 
> org.apache.geode.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:148)
>   at 
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:341)
>   at 
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:364)
>   at 
> org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest.testMultipleGfshClientToOneServer(ConcurrentDeployDUnitTest.java:67)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java: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.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   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.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 

[jira] [Resolved] (GEODE-1130) Session state modules DeltaEvent logs extraneous 'attribute is already a byte[]' message

[Barry Oglesby (JIRA)]

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

Barry Oglesby resolved GEODE-1130.
--
Resolution: Fixed

> Session state modules DeltaEvent logs extraneous 'attribute is already a 
> byte[]' message
> 
>
> Key: GEODE-1130
> URL: https://issues.apache.org/jira/browse/GEODE-1130
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>
> The following message is logged by {{DeltaEvent.blobifyValue}}:
> {noformat}
> [warning 2016/03/22 15:00:06.867 GMT+09:00   tid=0x60] Session 
> attribute is already a byte[] - problems may occur transmitting this delta.
> {noformat}
> Here:
> {noformat}if (value instanceof byte[]) {
>   LOG.warn("Session attribute is already a byte[] - problems may "
> + "occur transmitting this delta.");
> }
> {noformat}
> It can safely be removed.



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

[jira] [Commented] (GEODE-1130) Session state modules DeltaEvent logs extraneous 'attribute is already a byte[]' message

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1130:


Commit 5b122c795ef9156ab4b003e5a04c348baf9ffcf6 in geode's branch 
refs/heads/develop from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5b122c7 ]

GEODE-1130: Removed log message


> Session state modules DeltaEvent logs extraneous 'attribute is already a 
> byte[]' message
> 
>
> Key: GEODE-1130
> URL: https://issues.apache.org/jira/browse/GEODE-1130
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>
> The following message is logged by {{DeltaEvent.blobifyValue}}:
> {noformat}
> [warning 2016/03/22 15:00:06.867 GMT+09:00   tid=0x60] Session 
> attribute is already a byte[] - problems may occur transmitting this delta.
> {noformat}
> Here:
> {noformat}if (value instanceof byte[]) {
>   LOG.warn("Session attribute is already a byte[] - problems may "
> + "occur transmitting this delta.");
> }
> {noformat}
> It can safely be removed.



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

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #551 was successful.
---
Scheduled
1849 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[jira] [Updated] (GEODE-2844) Users need a default way to connect a client to an existing region on server

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-2844:
--
Issue Type: Sub-task  (was: Improvement)
Parent: GEODE-1887

> Users need a default way to connect a client to an existing region on server
> 
>
> Key: GEODE-2844
> URL: https://issues.apache.org/jira/browse/GEODE-2844
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Fred Krone
>Assignee: Darrel Schneider
>
> A ClientRegionShortcut is required when connecting a client to an existing 
> region.  The list is not very intutive and currently Proxy (the most logical 
> pick for default behavior) doesn't behave as it should in its Javadocs.  
> Regardless, users shouldn't have to read through a list of docs to figure out 
> which ClientRegionShortcut to use when trying to connect to an existing 
> Region on the server.
> Create a zero arg constructor:
> ClientCache.createClientRegionFactory().create()
> Or... even better... take out the createClientRegionFactory() step altogether:
> ClientCache.createRegion() which calls .createClientRegionFactory(default 
> shortcut).
> This will create a PROXY to an existing region on a server -- ie: all behvior 
> happens on the server.



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

[jira] [Commented] (GEODE-2913) Update Lucene documentation

[Diane Hardman (JIRA)]

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

Diane Hardman commented on GEODE-2913:
--

I noticed that the following 2 bullets were missing from the list of 
corrections:
 - Add gfsh commands: 'destroy lucene index' and 'describe lucene index'
 - To specify the Lucene index field which represents the entire object, use 
__REGION_VALUE_FIELD

Are these doc updates covered elsewhere?

> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .setXXX()
> .setYYY()
> .create()
> {code}
> *  Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create 
> the Lucene index before creating the region, even though this member does not 
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be 
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT  tid=0x1] 
> java.lang.IllegalStateException: Must create Lucene index full_index on 
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create 
> Lucene index full_index on region /data because it is defined in another 
> member.
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The 
> Lucene search will always be done on the server.  Besides, _you can't create 
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of 
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't, 
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results. 
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> *  Destroying a region will *NOT* automatically destroy any Lucene index 
> associated with that region. Instead, attempting to destroy a region with a 
> Lucene index will throw a colocated region exception. 
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation 
> chain cannot be destroyed, unless all its children 
> [[/cusip_index#_data.files]] are destroyed
> at 
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at 
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at 
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh: 
>   1. export region data
>   2. destroy Lucene index, destroy region 
>   3. create new index, create new region without user-defined business 
> logic callbacks
>   4. import data with option to turn on callbacks (to invoke Lucene Async 
> Event Listener to index the data)
>   5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not 
> supported.
> * Document security implementation and defaults.  If a user has security 
> configured for their cluster, creating a Lucene index requires DATA:MANAGE 
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE 
> privilege because a function is called (different from OQL which requires 
> only DATA:READ privilege). Here are all the required privileges for the gfsh 
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes requires CLUSTER:READ
> ** search index requires DATA:WRITE
> ** destroy index requires DATA:MANAGE:region
> * A user cannot create a Lucene index on a region that has eviction 
> configured with local destroy. If using Lucene indexing, eviction can only be 
> configured 

[jira] [Updated] (GEODE-2913) Update Lucene documentation

[Diane Hardman (JIRA)]

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

Diane Hardman updated GEODE-2913:
-
Description: 
Improvements to the code base that need to be reflected in the docs:
* Change LuceneService.createIndex to use a factory pattern
{code:java}
luceneService.createIndex(region, index, ...)
{code}
changes to
{code:java}
luceneService.createIndexFactory()
.setXXX()
.setYYY()
.create()
{code}
*  Lucene indexes will *NOT* be stored in off-heap memory.
* Document how to configure an index on accessors - you still need to create 
the Lucene index before creating the region, even though this member does not 
hold any region data.
If the index is not defined on the accessor, an exception like this will be 
thrown while attempting to create the region:
{quote}
[error 2017/05/02 15:19:26.018 PDT  tid=0x1] 
java.lang.IllegalStateException: Must create Lucene index full_index on region 
/data because it is defined in another member.
Exception in thread "main" java.lang.IllegalStateException: Must create Lucene 
index full_index on region /data because it is defined in another member.
at 
org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
at 
org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
{quote}
* Do not need to create a Lucene index on a client with a Proxy cache. The 
Lucene search will always be done on the server.  Besides, _you can't create an 
index on a client._
* If you configure Invalidates for region entries (alone or as part of 
expiration), these will *NOT* invalidate the Lucene indexes.
The problem with this is the index contains the keys, but the region doesn't, 
so the query produces results that don't exist.
In this test, the first time the query is run, it produces N valid results. The 
second time it is run it produces N empty results:
** load entries
** run query
** invalidate entries
** run query again
*  Destroying a region will *NOT* automatically destroy any Lucene index 
associated with that region. Instead, attempting to destroy a region with a 
Lucene index will throw a colocated region exception. 
An IllegalStateException is thrown:
{quote}
java.lang.IllegalStateException: The parent region [/data] in colocation chain 
cannot be destroyed, unless all its children [[/cusip_index#_data.files]] are 
destroyed
at 
org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
at 
org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
at 
org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
at 
DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
{quote}
* The process to change a Lucene index using gfsh: 
  1. export region data
  2. destroy Lucene index, destroy region 
  3. create new index, create new region without user-defined business 
logic callbacks
  4. import data with option to turn on callbacks (to invoke Lucene Async 
Event Listener to index the data)
  5. alter region to add user-defined business logic callbacks
* Make sure there are no references to replicated regions as they are not 
supported.
* Document security implementation and defaults.  If a user has security 
configured for their cluster, creating a Lucene index requires DATA:MANAGE 
privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE 
privilege because a function is called (different from OQL which requires only 
DATA:READ privilege). Here are all the required privileges for the gfsh 
commands:
** create index requires DATA:MANAGE:region
** describe index requires CLUSTER:READ
** list indexes requires CLUSTER:READ
** search index requires DATA:WRITE
** destroy index requires DATA:MANAGE:region
* A user cannot create a Lucene index on a region that has eviction configured 
with local destroy. If using Lucene indexing, eviction can only be configured 
with overflow to disk. In this case, only the region data is overflowed to 
disk, *NOT* the Lucene index. An UnsupportedOperationException is thrown:
{quote}
[error 2017/05/02 16:12:32.461 PDT  tid=0x1] 
java.lang.UnsupportedOperationException: Lucene indexes on regions with 
eviction and action local destroy are not supported
Exception in thread "main" java.lang.UnsupportedOperationException: Lucene 
indexes on regions with eviction and action local destroy are not supported
at 
org.apache.geode.cache.lucene.internal.LuceneRegionListener.beforeCreate(LuceneRegionListener.java:85)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.invokeRegionBefore(GemFireCacheImpl.java:3154)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3013)
at 

[jira] [Resolved] (GEODE-1775) CI failure: ParallelWANPropagationClientServerDUnitTest.testParallelPropagationWithClientServer

[xiaojian zhou (JIRA)]

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

xiaojian zhou resolved GEODE-1775.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> CI failure: 
> ParallelWANPropagationClientServerDUnitTest.testParallelPropagationWithClientServer
> ---
>
> Key: GEODE-1775
> URL: https://issues.apache.org/jira/browse/GEODE-1775
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Grace Meilen
>Assignee: Dan Smith
>  Labels: ci, flaky
> Fix For: 1.2.0
>
>
> {no format}
> :geode-wan:distributedTest
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationClientServerDUnitTest
>  > testParallelPropagationWithClientServer FAILED
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationClientServerDUnitTest$$Lambda$19/1746236140.run
>  in VM 4 running on Host 9ff79c8190b7 with 8 VMs
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
> at 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationClientServerDUnitTest.testParallelPropagationWithClientServer(ParallelWANPropagationClientServerDUnitTest.java:59)
> Caused by:
> com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: 
> com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: Primary 
> discovery failed.
> at 
> com.gemstone.gemfire.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:198)
> at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:550)
> at 
> com.gemstone.gemfire.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:763)
> at 
> com.gemstone.gemfire.cache.client.internal.RegisterInterestOp.execute(RegisterInterestOp.java:63)
> at 
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.registerInterest(ServerRegionProxy.java:376)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.processSingleInterest(LocalRegion.java:3968)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.registerInterest(LocalRegion.java:4058)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3873)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3867)
> at 
> com.gemstone.gemfire.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3863)
> at 
> com.gemstone.gemfire.internal.cache.wan.WANTestBase.createClientWithLocator(WANTestBase.java:2154)
> at 
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelWANPropagationClientServerDUnitTest.lambda$testParallelPropagationWithClientServer$cb73cba9$3(ParallelWANPropagationClientServerDUnitTest.java:59)
> Caused by:
> 
> com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: Primary 
> discovery failed.
> {no format}



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

Review Request 59210: GEODE-2912: Hot deploy for functions in deployed Jars

[Jared Stewart]

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

Review request for geode.


Repository: geode


Description
---

GEODE-2912: Hot deploy for functions in deployed Jars

- New versions of a function now deploy over top the old versions without an 
intermediate undeploy


Diffs
-

  geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java 
acb7d227a4f67c749cbc11ee2fdae8651d3bc5d6 
  geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java 
df3f10b8cba9bdca8429bdcf8567b654d36ea475 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
 697247701f883a5532ac0118ff116ac6562776d4 


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


Testing
---

Precheckin running


Thanks,

Jared Stewart

Re: Review Request 59206: GEODE-2836: CacheLoader now extends Declarable

[Jared Stewart]

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

(Updated May 11, 2017, 9:45 p.m.)


Review request for geode.


Changes
---

CacheCallback extends declarable rather than CacheLoader


Repository: geode


Description
---

GEODE-2836: CacheLoader now extends Declarable


Diffs (updated)
-

  geode-core/src/main/java/org/apache/geode/cache/CacheCallback.java a272afb 
  geode-core/src/main/java/org/apache/geode/cache/Declarable.java 57e1e63 


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

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


Testing
---

Precheckin running


Thanks,

Jared Stewart

Re: Review Request 59206: GEODE-2836: CacheLoader now extends Declarable

[Jared Stewart]

> On May 11, 2017, 9:38 p.m., Darrel Schneider wrote:
> > Instead of having CacheLoader extend Declarable I think you should have 
> > changed CacheCallback to extends Declarable.
> > CacheLoader is too narrow. So is CacheLoader and CacheListener. I know the 
> > jira ticket focused on CacheLoader and mentioned CacheListener in its 
> > description but we have lots of things that can be declared on cache.xml 
> > and I think CacheCallback covers them all.

Good point, I've uploaded a new diff to make this change.


- Jared


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


On May 11, 2017, 9:16 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59206/
> ---
> 
> (Updated May 11, 2017, 9:16 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2836: CacheLoader now extends Declarable
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/cache/CacheLoader.java 
> 88128166fa24a4160d28f478e4e546a1e1dbf335 
>   geode-core/src/main/java/org/apache/geode/cache/Declarable.java 
> 57e1e6316395a62588fac430b1f807684b3335fb 
> 
> 
> Diff: https://reviews.apache.org/r/59206/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 59206: GEODE-2836: CacheLoader now extends Declarable

[Darrel Schneider]

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



Instead of having CacheLoader extend Declarable I think you should have changed 
CacheCallback to extends Declarable.
CacheLoader is too narrow. So is CacheLoader and CacheListener. I know the jira 
ticket focused on CacheLoader and mentioned CacheListener in its description 
but we have lots of things that can be declared on cache.xml and I think 
CacheCallback covers them all.

- Darrel Schneider


On May 11, 2017, 2:16 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59206/
> ---
> 
> (Updated May 11, 2017, 2:16 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2836: CacheLoader now extends Declarable
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/cache/CacheLoader.java 
> 88128166fa24a4160d28f478e4e546a1e1dbf335 
>   geode-core/src/main/java/org/apache/geode/cache/Declarable.java 
> 57e1e6316395a62588fac430b1f807684b3335fb 
> 
> 
> Diff: https://reviews.apache.org/r/59206/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 59206: GEODE-2836: CacheLoader now extends Declarable

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On May 11, 2017, 9:16 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59206/
> ---
> 
> (Updated May 11, 2017, 9:16 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2836: CacheLoader now extends Declarable
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/cache/CacheLoader.java 
> 88128166fa24a4160d28f478e4e546a1e1dbf335 
>   geode-core/src/main/java/org/apache/geode/cache/Declarable.java 
> 57e1e6316395a62588fac430b1f807684b3335fb 
> 
> 
> Diff: https://reviews.apache.org/r/59206/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

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

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-1887:
--
Issue Type: Wish  (was: Bug)

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



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

[jira] [Updated] (GEODE-2452) invalidateRegion on a CACHING_PROXY region throws NPE

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-2452:
--
Issue Type: Sub-task  (was: Bug)
Parent: GEODE-1887

> invalidateRegion on a CACHING_PROXY region throws NPE
> -
>
> Key: GEODE-2452
> URL: https://issues.apache.org/jira/browse/GEODE-2452
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Swapnil Bawaskar
>
> Calling invalidateRegion on a CACHING_PROXY threw the following Exception:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
>   at 
> org.apache.geode.cache.client.internal.InvalidateOp$InvalidateOpImpl.(InvalidateOp.java:67)
>   at 
> org.apache.geode.cache.client.internal.InvalidateOp.execute(InvalidateOp.java:47)
>   at 
> org.apache.geode.cache.client.internal.ServerRegionProxy.invalidate(ServerRegionProxy.java:221)
>   at 
> org.apache.geode.internal.cache.LocalRegion.serverInvalidate(LocalRegion.java:3149)
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.invalidate(AbstractRegionMap.java:2134)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.invalidateExistingEntry(LocalRegionDataView.java:67)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicInvalidate(LocalRegion.java:5223)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicInvalidate(LocalRegion.java:5187)
>   at 
> org.apache.geode.internal.cache.LocalRegion.invalidateAllEntries(LocalRegion.java:8045)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicInvalidateRegion(LocalRegion.java:7398)
>   at 
> org.apache.geode.internal.cache.LocalRegion.invalidateRegion(LocalRegion.java:1647)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.invalidateRegion(AbstractRegion.java:342)
> {noformat}



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

[jira] [Updated] (GEODE-2721) Create on-server regions from the client

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-2721:
--
Issue Type: Sub-task  (was: Improvement)
Parent: GEODE-1887

> Create on-server regions from the client
> 
>
> Key: GEODE-2721
> URL: https://issues.apache.org/jira/browse/GEODE-2721
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Fred Krone
>
> Client's should be enabled to create server-side regions.  Currently, regions 
> must be created either via gfsh or cache.xml, then you must PROXY into these 
> existing regions.  We're assuming here that the developer knows about the 
> existing region already, or can create it via gfsh or cache.xml.  If the 
> Region does exist, fine.  But if it doesn't it seems redundant to ask a 
> developer to go create it elsewhere-- why not just create/get a new one it 
> programmatically at that point?  
> ACCEPTANCE:
> Server side region created from client.
> Current way (gets a handle to a client):
> ClientCache cache = new ClientCacheFactory().addPoolLocator("localhost", 
> 10334).create();
> Region clientRegion = 
> cache.createClientRegionFactory(ClientRegionShortcut.PROXY).create("region1");
> New way (creating the server side region programmatically):
> ClientCache cache = new ClientCacheFactory().addPoolLocator("localhost", 
> 10334).create();
> Region region = cache.createRegion("region1");



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

[jira] [Updated] (GEODE-2721) Create on-server regions from the client

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-2721:
--
Description: 
Client's should be enabled to create server-side regions.  Currently, regions 
must be created either via gfsh or cache.xml, then you must PROXY into these 
existing regions.  We're assuming here that the developer knows about the 
existing region already, or can create it via gfsh or cache.xml.  If the Region 
does exist, fine.  But if it doesn't it seems redundant to ask a developer to 
go create it elsewhere-- why not just create/get a new one it programmatically 
at that point?  

ACCEPTANCE:
Server side region created from client.

Current way (gets a handle to a client):
ClientCache cache = new ClientCacheFactory().addPoolLocator("localhost", 
10334).create();
Region clientRegion = 
cache.createClientRegionFactory(ClientRegionShortcut.PROXY).create("region1");

New way (creating the server side region programmatically):
ClientCache cache = new ClientCacheFactory().addPoolLocator("localhost", 
10334).create();
Region region = cache.createRegion("region1");







  was:
This is an overarching story for new client API work.  

AC: can create, edit and delete a server-side region from the client.
AC: can easy perform CRUD operations on entries on a region.
AC: can get collection from a server side region (getKeys(), etc))


> Create on-server regions from the client
> 
>
> Key: GEODE-2721
> URL: https://issues.apache.org/jira/browse/GEODE-2721
> Project: Geode
>  Issue Type: Improvement
>Reporter: Fred Krone
>
> Client's should be enabled to create server-side regions.  Currently, regions 
> must be created either via gfsh or cache.xml, then you must PROXY into these 
> existing regions.  We're assuming here that the developer knows about the 
> existing region already, or can create it via gfsh or cache.xml.  If the 
> Region does exist, fine.  But if it doesn't it seems redundant to ask a 
> developer to go create it elsewhere-- why not just create/get a new one it 
> programmatically at that point?  
> ACCEPTANCE:
> Server side region created from client.
> Current way (gets a handle to a client):
> ClientCache cache = new ClientCacheFactory().addPoolLocator("localhost", 
> 10334).create();
> Region clientRegion = 
> cache.createClientRegionFactory(ClientRegionShortcut.PROXY).create("region1");
> New way (creating the server side region programmatically):
> ClientCache cache = new ClientCacheFactory().addPoolLocator("localhost", 
> 10334).create();
> Region region = cache.createRegion("region1");



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

[jira] [Commented] (GEODE-2874) StringIndexOutOfBoundsException while initializing logger

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra commented on GEODE-2874:


[~jstewart] it seems log file doesn't has ".". 
a. start client with log-file="clientLog".
b. you should see clientLog file
c. now restart client,

That should reproduce this issue

> StringIndexOutOfBoundsException while initializing logger
> -
>
> Key: GEODE-2874
> URL: https://issues.apache.org/jira/browse/GEODE-2874
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -1
>   at java.lang.String.substring(String.java:1967)
>   at 
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.calcNextChildId(MainWithChildrenRollingFileHandler.java:47)
>   at 
> org.apache.geode.internal.logging.ManagerLogWriter.getLogNameForOldMainLog(ManagerLogWriter.java:330)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.createLogWriterAppender(LogWriterAppenders.java:144)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:72)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:88)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:304)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207)
>   at GeodeClient.GeodeClient(GeodeClient.java:22)
>   at GeodeClient.main(GeodeClient.java:10)



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

[jira] [Updated] (GEODE-2721) Create on-server regions from the client

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-2721:
--
Summary: Create on-server regions from the client  (was: As a developer I 
want a strong client so that I can create regions and edit entries easily)

> Create on-server regions from the client
> 
>
> Key: GEODE-2721
> URL: https://issues.apache.org/jira/browse/GEODE-2721
> Project: Geode
>  Issue Type: Improvement
>Reporter: Fred Krone
>
> This is an overarching story for new client API work.  
> AC: can create, edit and delete a server-side region from the client.
> AC: can easy perform CRUD operations on entries on a region.
> AC: can get collection from a server side region (getKeys(), etc))



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

[jira] [Commented] (GEODE-11) Lucene Integration

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-11:
--

Commit c8f337c0857686eab64236245f642a1e028e0ca4 in geode's branch 
refs/heads/feature/GEODE-2632-15 from zhouxh
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c8f337c ]

GEODE-11: add unit test for soundex analyzer


> Lucene Integration
> --
>
> Key: GEODE-11
> URL: https://issues.apache.org/jira/browse/GEODE-11
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, querying
>Reporter: Dan Smith
>Assignee: xiaojian zhou
>  Labels: experimental
> Fix For: 1.2.0
>
>
> This is a feature that has been under development for GemFire but was not 
> part of the initial drop of code for geode.
> Allow Lucene indexes to be stored in Geode regions allowing users to do text 
> searches on data stored in Geode. 



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2883:


Commit 68935caea1d158375d6bf94c73c8f685eda01211 in geode's branch 
refs/heads/feature/GEODE-2632-15 from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=68935ca ]

GEODE-2883: Fix GFSH gc heap size output


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



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

[jira] [Commented] (GEODE-2897) Add a GitHub PR template

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2897:


Commit 5f6323ba50bee4cd0ad6d268ed99233e5af5f840 in geode's branch 
refs/heads/feature/GEODE-2632-15 from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5f6323b ]

GEODE-2897 Add PR template for github


> Add a GitHub PR template
> 
>
> Key: GEODE-2897
> URL: https://issues.apache.org/jira/browse/GEODE-2897
> Project: Geode
>  Issue Type: Improvement
>  Components: github
>Reporter: Anthony Baker
>Assignee: Anthony Baker
> Fix For: 1.2.0
>
>
> We should add a PR template to help guide new contributors.
> Here's a good example:
> https://github.com/apache/nifi/blob/master/.github/PULL_REQUEST_TEMPLATE.md



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2859:


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

GEODE-2859: Fix race in ShowDeadlockDUnitTest


> 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
>Assignee: Jared Stewart
>
> 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 

[jira] [Commented] (GEODE-2812) Add API to get list of live locators

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2812:


Commit 8239e6fd64e01827d6df78c3c62fc886337cc011 in geode's branch 
refs/heads/feature/GEODE-2632-15 from [~masaki.yamakawa]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=8239e6f ]

GEODE-2812: Add API to get list of live locators

I fixed 'gradlew spotlessApply' to fix them.

*
geode-core/src/main/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImpl.java
*
geode-core/src/test/java/org/apache/geode/cache/client/internal/AutoConnectionSourceDUnitTest.java


> Add API to get list of live locators
> 
>
> Key: GEODE-2812
> URL: https://issues.apache.org/jira/browse/GEODE-2812
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> There is a Geode cluster using a logical member group, and from the client, 
> the connection pool to the logical member group is connected using the 
> PoolFactory API at the timing when connection becomes necessary.
> At this time, even though the locator that was running at the initial 
> connection stops due to reasons such as regular maintenance etc., even if the 
> alternate locator is started before maintenance, I can not connect to the 
> locator in the static initial list.
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupA").create("pool1");
> # Geode cluster:start locator [ localhost:10335 ].
> # Geode cluster:stop locator [ localhost:10334 ].
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupB").create("pool2");
> Therefore, I would like to decide the connection destination based on the 
> live locator list of another logical member group.
> I added an API that can get the list of live locators from the Pool. Use the 
> API as follows:
> {code:java|borderStyle=solid}
> Pool pool = PoolManager.createFactory()
>   .addLocator("localhost", 10334)
>   .setSubscriptionEnabled(true).setServerGroup("GroupA")
>   .create("GroupAPool");
> List = pool.getLiveLocators();
> {code}
> {quote}
> Note:
> The list of live locators gets the result of the UpdateLocatorListTask 
> periodically running in AutoConnectionSourceImpl.
> Therefore, whether or not it is alive will cause a time lag, depending on the 
> task execution interval.
> Also, the result of ExplicitConnectionSourceImpl without using a locator is 
> always empty.
> {quote}



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

[jira] [Commented] (GEODE-2909) Fix 2 typos in Lucene integration docs

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2909:


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

GEODE-2909  CTR fix of 2 typos in Lucene documentation


> Fix 2 typos in Lucene integration docs
> --
>
> Key: GEODE-2909
> URL: https://issues.apache.org/jira/browse/GEODE-2909
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> The 2 typos to be fixed:
> - In the Java API Example subsection, {{RegionShortcut}} is misspelled as 
> {{RegionShutcut}}.
> - For consistency, add a period to the end of the description of {{gfsh 
> search lucene}} in the Gfsh API subsection.
> These typos are minor.  Fix them under a CTR (commit then review) process.



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

[jira] [Commented] (GEODE-2907) Remove @Experimental tag from the Lucene module

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2907:


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

GEODE-2907: Removed @Experimental tag from the Lucene module

* Removed the @experimental tag fromt the files in Lucene module.
* Improve on the javadocs for the interfaces present in the Lucene 
module.

This closes #503


> Remove @Experimental tag from the Lucene module
> ---
>
> Key: GEODE-2907
> URL: https://issues.apache.org/jira/browse/GEODE-2907
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
>
> Issue:
> Remove the @Experimental tag from the files in the Lucene module to prepare 
> Apache Geode for the next release.
> Also improve on the javadocs for the interfaces present in the Lucene module.



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

Review Request 59206: GEODE-2836: CacheLoader now extends Declarable

[Jared Stewart]

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

Review request for geode.


Repository: geode


Description
---

GEODE-2836: CacheLoader now extends Declarable


Diffs
-

  geode-core/src/main/java/org/apache/geode/cache/CacheLoader.java 
88128166fa24a4160d28f478e4e546a1e1dbf335 
  geode-core/src/main/java/org/apache/geode/cache/Declarable.java 
57e1e6316395a62588fac430b1f807684b3335fb 


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


Testing
---

Precheckin running


Thanks,

Jared Stewart

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2889:


Commit 1d3e0d53f2182f9ca9c680bb8927e70f204ce89d in geode's branch 
refs/heads/feature/GEODE-2632-15 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=1d3e0d5 ]

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

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

This closes #494


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



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

[jira] [Commented] (GEODE-2895) CI failure: OldFreeListOffHeapRegionJUnitTest.testLocalPersistent

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2895:


Commit 7b2f904f6c5d96c6bf747ddbe2f856b53e2009a5 in geode's branch 
refs/heads/feature/GEODE-2632-15 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=7b2f904 ]

GEODE-2895: fix flaky test


> CI failure: OldFreeListOffHeapRegionJUnitTest.testLocalPersistent
> -
>
> Key: GEODE-2895
> URL: https://issues.apache.org/jira/browse/GEODE-2895
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Lynn Gallinat
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> FIX: wait up to 60 seconds to check ma.getUsedMemory() 
>  
> {noformat}
> org.apache.geode.internal.offheap.OldFreeListOffHeapRegionJUnitTest > 
> testLocalPersistent FAILED
> java.lang.AssertionError: expected:<0> but was:<24>
> java.lang.AssertionError: expected:<0> but was:<24>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:645)
>   at org.junit.Assert.assertEquals(Assert.java:631)
>   at 
> org.apache.geode.internal.offheap.OffHeapRegionBase.doRegionTest(OffHeapRegionBase.java:451)
>   at 
> org.apache.geode.internal.offheap.OffHeapRegionBase.doRegionTest(OffHeapRegionBase.java:211)
>   at 
> org.apache.geode.internal.offheap.OffHeapRegionBase.testLocalPersistent(OffHeapRegionBase.java:618)
>   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.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.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)
>   

[jira] [Commented] (GEODE-2874) StringIndexOutOfBoundsException while initializing logger

[Jared Stewart (JIRA)]

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

Jared Stewart commented on GEODE-2874:
--

[~hitesh.khamesra] Do you have any info about how to reproduce this error?  
Thanks!

> StringIndexOutOfBoundsException while initializing logger
> -
>
> Key: GEODE-2874
> URL: https://issues.apache.org/jira/browse/GEODE-2874
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -1
>   at java.lang.String.substring(String.java:1967)
>   at 
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.calcNextChildId(MainWithChildrenRollingFileHandler.java:47)
>   at 
> org.apache.geode.internal.logging.ManagerLogWriter.getLogNameForOldMainLog(ManagerLogWriter.java:330)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.createLogWriterAppender(LogWriterAppenders.java:144)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:72)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:88)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:304)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207)
>   at GeodeClient.GeodeClient(GeodeClient.java:22)
>   at GeodeClient.main(GeodeClient.java:10)



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

[jira] [Assigned] (GEODE-2913) Update Lucene documentation

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller reassigned GEODE-2913:
--

Assignee: Karen Smoler Miller

> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .setXXX()
> .setYYY()
> .create()
> {code}
> *  Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create 
> the Lucene index before creating the region, even though this member does not 
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be 
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT  tid=0x1] 
> java.lang.IllegalStateException: Must create Lucene index full_index on 
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create 
> Lucene index full_index on region /data because it is defined in another 
> member.
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The 
> Lucene search will always be done on the server.  Besides, _you can't create 
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of 
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't, 
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results. 
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> *  Destroying a region will *NOT* automatically destroy any Lucene index 
> associated with that region. Instead, attempting to destroy a region with a 
> Lucene index will throw a colocated region exception. 
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation 
> chain cannot be destroyed, unless all its children 
> [[/cusip_index#_data.files]] are destroyed
> at 
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at 
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at 
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh: 
>   1. export region data
>   2. destroy Lucene index, destroy region 
>   3. create new index, create new region without user-defined business 
> logic callbacks
>   4. import data with option to turn on callbacks (to invoke Lucene Async 
> Event Listener to index the data)
>   5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not 
> supported.
> * Document security implementation and defaults.  If a user has security 
> configured for their cluster, creating a Lucene index requires DATA:MANAGE 
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE 
> privilege because a function is called (different from OQL which requires 
> only DATA:READ privilege). Here are all the required privileges for the gfsh 
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes requires CLUSTER:READ
> ** search index requires DATA:WRITE
> ** destroy index requires DATA:MANAGE:region
> * A user cannot create a Lucene index on a region that has eviction 
> configured with local destroy. If using Lucene indexing, eviction can only be 
> configured with overflow to disk. In this case, only the region data is 
> overflowed to disk, *NOT* the Lucene index. An UnsupportedOperationException 
> is thrown:
> {quote}
> [error 2017/05/02 16:12:32.461 PDT  tid=0x1] 
> java.lang.UnsupportedOperationException: Lucene indexes on regions with 

[jira] [Updated] (GEODE-2892) Add sizeOnServer and emptyOnServer to Region

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-2892:
--
Description: 
To lower confusion while also not breaking backwards compatibility Region needs 
explicit "onServer" methods.

sizeOnServer 
isEmptyOnServer 

These could also be named something like size(boolean localSize) to keep the 
API a less wordy.

ACCEPTANCE:
When a developer uses these methods then the result should be from the 
server-side.   This includes accessor Regions.
JavaDocs should be updated accordingly.

  was:
To lower confusion while also not breaking backwards compatibility Region needs 
explicit "onServer" methods.

sizeOnServer 
emptyOnServer 

These could also be named something like size(boolean localSize) to keep the 
API a less wordy.

ACCEPTANCE:
When a developer uses these methods then the result should be from the 
server-side.   This includes accessor Regions.
JavaDocs should be updated accordingly.


> Add sizeOnServer and emptyOnServer to Region
> 
>
> Key: GEODE-2892
> URL: https://issues.apache.org/jira/browse/GEODE-2892
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Fred Krone
>Assignee: Fred Krone
>
> To lower confusion while also not breaking backwards compatibility Region 
> needs explicit "onServer" methods.
> sizeOnServer 
> isEmptyOnServer 
> These could also be named something like size(boolean localSize) to keep the 
> API a less wordy.
> ACCEPTANCE:
> When a developer uses these methods then the result should be from the 
> server-side.   This includes accessor Regions.
> JavaDocs should be updated accordingly.



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

[jira] [Assigned] (GEODE-2892) Add sizeOnServer and emptyOnServer to Region

[Fred Krone (JIRA)]

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

Fred Krone reassigned GEODE-2892:
-

Assignee: Fred Krone

> Add sizeOnServer and emptyOnServer to Region
> 
>
> Key: GEODE-2892
> URL: https://issues.apache.org/jira/browse/GEODE-2892
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Fred Krone
>Assignee: Fred Krone
>
> To lower confusion while also not breaking backwards compatibility Region 
> needs explicit "onServer" methods.
> sizeOnServer 
> emptyOnServer 
> These could also be named something like size(boolean localSize) to keep the 
> API a less wordy.
> ACCEPTANCE:
> When a developer uses these methods then the result should be from the 
> server-side.   This includes accessor Regions.
> JavaDocs should be updated accordingly.



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

[jira] [Created] (GEODE-2913) Update Lucene documentation

[Karen Smoler Miller (JIRA)]

Karen Smoler Miller created GEODE-2913:
--

 Summary: Update Lucene documentation
 Key: GEODE-2913
 URL: https://issues.apache.org/jira/browse/GEODE-2913
 Project: Geode
  Issue Type: Bug
  Components: docs
Reporter: Karen Smoler Miller


Improvements to the code base that need to be reflected in the docs:
* Change LuceneService.createIndex to use a factory pattern
{code:java}
luceneService.createIndex(region, index, ...)
{code}
changes to
{code:java}
luceneService.createIndexFactory()
.setXXX()
.setYYY()
.create()
{code}
*  Lucene indexes will *NOT* be stored in off-heap memory.
* Document how to configure an index on accessors - you still need to create 
the Lucene index before creating the region, even though this member does not 
hold any region data.
If the index is not defined on the accessor, an exception like this will be 
thrown while attempting to create the region:
{quote}
[error 2017/05/02 15:19:26.018 PDT  tid=0x1] 
java.lang.IllegalStateException: Must create Lucene index full_index on region 
/data because it is defined in another member.
Exception in thread "main" java.lang.IllegalStateException: Must create Lucene 
index full_index on region /data because it is defined in another member.
at 
org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
at 
org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
{quote}
* Do not need to create a Lucene index on a client with a Proxy cache. The 
Lucene search will always be done on the server.  Besides, _you can't create an 
index on a client._
* If you configure Invalidates for region entries (alone or as part of 
expiration), these will *NOT* invalidate the Lucene indexes.
The problem with this is the index contains the keys, but the region doesn't, 
so the query produces results that don't exist.
In this test, the first time the query is run, it produces N valid results. The 
second time it is run it produces N empty results:
** load entries
** run query
** invalidate entries
** run query again
*  Destroying a region will *NOT* automatically destroy any Lucene index 
associated with that region. Instead, attempting to destroy a region with a 
Lucene index will throw a colocated region exception. 
An IllegalStateException is thrown:
{quote}
java.lang.IllegalStateException: The parent region [/data] in colocation chain 
cannot be destroyed, unless all its children [[/cusip_index#_data.files]] are 
destroyed
at 
org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
at 
org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
at 
org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
at 
DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
{quote}
* The process to change a Lucene index using gfsh: 
  1. export region data
  2. destroy Lucene index, destroy region 
  3. create new index, create new region without user-defined business 
logic callbacks
  4. import data with option to turn on callbacks (to invoke Lucene Async 
Event Listener to index the data)
  5. alter region to add user-defined business logic callbacks
* Make sure there are no references to replicated regions as they are not 
supported.
* Document security implementation and defaults.  If a user has security 
configured for their cluster, creating a Lucene index requires DATA:MANAGE 
privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE 
privilege because a function is called (different from OQL which requires only 
DATA:READ privilege). Here are all the required privileges for the gfsh 
commands:
** create index requires DATA:MANAGE:region
** describe index requires CLUSTER:READ
** list indexes requires CLUSTER:READ
** search index requires DATA:WRITE
** destroy index requires DATA:MANAGE:region
* A user cannot create a Lucene index on a region that has eviction configured 
with local destroy. If using Lucene indexing, eviction can only be configured 
with overflow to disk. In this case, only the region data is overflowed to 
disk, *NOT* the Lucene index. An UnsupportedOperationException is thrown:
{quote}
[error 2017/05/02 16:12:32.461 PDT  tid=0x1] 
java.lang.UnsupportedOperationException: Lucene indexes on regions with 
eviction and action local destroy are not supported
Exception in thread "main" java.lang.UnsupportedOperationException: Lucene 
indexes on regions with eviction and action local destroy are not supported
at 
org.apache.geode.cache.lucene.internal.LuceneRegionListener.beforeCreate(LuceneRegionListener.java:85)
at 

[jira] [Commented] (GEODE-2891) connect-timeout violation in C++ Native Client

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett commented on GEODE-2891:
-

[~gregvo] You need to make sure that issues you report are for the open source 
project and not for the close source commercial offering. For support on the 
commercial offering you need to go through support channels. You issue has been 
marked resolved as Invalid. I you can correct the issue you can re-open it.

> connect-timeout violation in C++ Native Client
> --
>
> Key: GEODE-2891
> URL: https://issues.apache.org/jira/browse/GEODE-2891
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Gregory Vortman
> Attachments: gemfire-connect-timeout-violation.docx
>
>
> 1.C++ native client doesn’t honour read-timeout-milli-sec in a consistent 
> way while connecting to a server
> 2.The lock on the connection pool has a very high granularity. Even if 
> the client can’t connect to one server, all other threads which are working 
> with totally different servers get affected by it



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

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

[Jacob Barrett]

On Thu, May 4, 2017 at 2:14 PM, Jacob Barrett  wrote:

> > > One benefit of messageHeader with chunk is that, it gives us ability to
> > > write different messages(multiplexing) on same socket. And if thread is
> > > ready it can write its message. Though we are not there yet, but that
> will
> > > require for single socket async architecture.
> > >
> >
> > I wouldn't tackle that at this layer. I would suggest adding a layer
> > between the message and TCP that creates channels that are opaque to the
> > message layer above. The message layer wouldn't know if it was talking to
> > multiple sockets to the client or single socket with multiple channels.
>
> Though we haven't really discussed it explicitly, the new protocol is
> adding the correlationID in the expectation that at some point it will be
> possible to execute requests out-of-order. One alternative to correlationID
> if we had multiple channels would be to use one channel per message or set
> of (ordered) messages. This would be a bit expensive if we used separate
> sockets for each, but if we had channels built into the protocol, it would
> be fine. The other use of correlationID might be for retries or to check up
> on a message after some issue leading to a disconnect. However, we have the
> EventID for that.
>
> As far as I know, we don't have the async, out-of-order functionality yet.
> I believe that in the current protocol, messages are ordered and
> synchronous -- they only happen in the order they're sent, and each
> operation blocks for the previous one to finish (though you could use
> multiple connections to get similar functionality).
>


My discussion here was around the concept of interleaving chunks of
individual messages not out of order responses of individual messages. From
the end user's perspective though whether we used correlation IDs or
ordered request/response over channels is irrelevant. At that level the API
should be asynchronous anyway. Underneath we can decide that if a single
channel/socket can have out of order messaging (not to be confused with out
of order partial message interleaving) or correlation ID.

Interleaving meaning
[Req1.1][Req2.1][Res2.1][Req1.2][Res1.1][Res2.2][Res1.2]
Correlation and part index required

Out of order meaning:
[Req1][Req2][Res2][Res2]
Correlation ID required

In order over channel:
1: [Req.1]  [Req.2][Res.1]   [Res.2]
2:[Req.1][Res.1]  [Res.2]
No correlation or ID required. Each request pulls a channel from a pool.
Naive approach is sockets, advanced is channel sublayer on the stack.

I really think In Order Over makes life easier. Maybe a hybrid approach
exists with Correlation IDs and Channels but really you can solve the same
problem with just channels, just more of them. At a Channel level it would
look synchronous request/response.

-Jake

JetBrains ReSharper License

[Jacob Barrett]

Has anyone on the project already applied to JetBrains for a Open Source
license for ReSharper of the Geode Project?

JetBrains offers complimentary licenses to Apache projects for use by their
contributors.
https://www.jetbrains.com/buy/opensource/?product=resharper

If nobody has applied I will make the application.

-Jake

[jira] [Updated] (GEODE-1130) Session state modules DeltaEvent logs extraneous 'attribute is already a byte[]' message

[Barry Oglesby (JIRA)]

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

Barry Oglesby updated GEODE-1130:
-
Description: 
The following message is logged by {{DeltaEvent.blobifyValue}}:
{noformat}
[warning 2016/03/22 15:00:06.867 GMT+09:00   tid=0x60] Session 
attribute is already a byte[] - problems may occur transmitting this delta.
{noformat}
Here:
{noformat}if (value instanceof byte[]) {
  LOG.warn("Session attribute is already a byte[] - problems may "
+ "occur transmitting this delta.");
}
{noformat}
It can safely be removed.

  was:
The following message is logged by {{DeltaEvent.blobifyValue}}:
{noformat}
[warning 2016/03/22 15:00:06.867 GMT+09:00   tid=0x60] Session 
attribute is already a byte[] - problems may occur transmitting this delta.
{noformat}
Here:
{noformat}if (value instanceof byte[]) {
  LOG.warn("Session attribute is already a byte[] - problems may "
+ "occur transmitting this delta.");
}
{noformat}
I can safely be removed.


> Session state modules DeltaEvent logs extraneous 'attribute is already a 
> byte[]' message
> 
>
> Key: GEODE-1130
> URL: https://issues.apache.org/jira/browse/GEODE-1130
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>
> The following message is logged by {{DeltaEvent.blobifyValue}}:
> {noformat}
> [warning 2016/03/22 15:00:06.867 GMT+09:00   tid=0x60] Session 
> attribute is already a byte[] - problems may occur transmitting this delta.
> {noformat}
> Here:
> {noformat}if (value instanceof byte[]) {
>   LOG.warn("Session attribute is already a byte[] - problems may "
> + "occur transmitting this delta.");
> }
> {noformat}
> It can safely be removed.



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

[jira] [Resolved] (GEODE-387) GatewayReceivers configured using cache xml should be started after the regions are created

[Barry Oglesby (JIRA)]

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

Barry Oglesby resolved GEODE-387.
-
Resolution: Duplicate

This is the same as GEODE-1814.

> GatewayReceivers configured using cache xml should be started after the 
> regions are created
> ---
>
> Key: GEODE-387
> URL: https://issues.apache.org/jira/browse/GEODE-387
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>
> Currently, {{GatewayReceivers}} configured using cache xml are started before 
> the {{Regions}} in that xml. This can cause data loss since a remote 
> {{GatewaySender}} could connect to that {{GatewayReceiver}} and send batches 
> before the {{Regions}} are created.
> First, the {{GatewayReceiver}} is started:
> {noformat}
> [info 2015/04/29 16:30:38.644 PDT host1  tid=0x1] The GatewayReceiver 
> started on port : 1,575
> {noformat}
> Then, events start being received and dropped:
> {noformat}
> [warning 2015/04/29 16:30:38.978 PDT host1  Thread 1> tid=0x7b] Server connection from 
> [identity(xx.x.xx.xx(host1:6372):27373,connection=1; port=36493]: Wrote 
> batch exception: 
> com.gemstone.gemfire.internal.cache.wan.BatchException70: Exception occurred 
> while processing a batch on the receiver running on DistributedSystem with 
> Id: 2, DistributedMember on which the receiver is running: 
> xx.x.xx.xxx(host1:25784):3298
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.command.GatewayReceiverCommand.cmdExecute(GatewayReceiverCommand.java:648)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:182)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:789)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:920)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1165)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:577)
>   at java.lang.Thread.run(Thread.java:724)
> Caused by: com.gemstone.gemfire.cache.RegionDestroyedException: Region /trade 
> was not found during batch create request 0
>   at 
> com.gemstone.gemfire.internal.cache.tier.sockets.command.GatewayReceiverCommand.cmdExecute(GatewayReceiverCommand.java:288)
>   ... 8 more
> {noformat}
> Finally, the region is created:
> {noformat}
> [info 2015/04/29 16:30:39.203 PDT host1  tid=0x1] Partitioned Region 
> /trade is born with prId=21 ident:#trade
> {noformat}
> In {{CacheCreation.create}}, the {{GatewayReceiver}} is created and started 
> before the regions are initialized. For comparison, the {{GatewayHub}} (which 
> is the predecessor to the {{GatewayReceiver}}) is started after the regions 
> are created. This is the way it should be.



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2859:


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

GEODE-2859: Fix race in ShowDeadlockDUnitTest


> 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
>Assignee: Jared Stewart
>
> 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 

[GitHub] geode issue #504: GEODE-254: Removed deprecated Region.keys and Region.entri...

[dschneider-pivotal]

Github user dschneider-pivotal commented on the issue:

https://github.com/apache/geode/pull/504
  
Yes, pull it in


---
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] [Resolved] (GEODE-2465) FileSystem should not remove chunks if another file has references to chunk

[Jason Huynh (JIRA)]

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

Jason Huynh resolved GEODE-2465.

Resolution: Not A Bug

This was thought to be possible but we have yet to see this be an issue.  Will 
mark this as not a bug at this point

> FileSystem should not remove chunks if another file has references to chunk
> ---
>
> Key: GEODE-2465
> URL: https://issues.apache.org/jira/browse/GEODE-2465
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>
> Currently we remove all chunks associated with a file when deleting a file 
> through the FileSystem.  We also remove chunks during reading (if there are 
> more chunks than expected while reading).
> In GEODE-2459 we fixed an issue where a renamed file was being deleted and 
> the chunks were being removed.
> In this case, we probably want to prevent the scenario where a "destination 
> file" is removed and somehow the "source" file remained.  
> We have not seen this occur yet, but it would be possible



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

[jira] [Assigned] (GEODE-2912) Real hot deploy of functions via gfsh

[Jared Stewart (JIRA)]

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

Jared Stewart reassigned GEODE-2912:


Assignee: Jared Stewart

> Real hot deploy of functions via gfsh
> -
>
> Key: GEODE-2912
> URL: https://issues.apache.org/jira/browse/GEODE-2912
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> A user ought to be able to deploy a Jar file containing a new version of a 
> Function without resulting in any failed function executions.



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

[jira] [Closed] (GEODE-150) Implementing user defined aggregate functions in OQL

[Dan Smith (JIRA)]

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

Dan Smith closed GEODE-150.
---

> Implementing user defined aggregate functions in OQL
> 
>
> Key: GEODE-150
> URL: https://issues.apache.org/jira/browse/GEODE-150
> Project: Geode
>  Issue Type: New Feature
>  Components: querying
>Reporter: Amogh Shetkar
>Assignee: Amogh Shetkar
>  Labels: experimental
>
> Opening this jira for Asif until he gets his jira account working.



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

[jira] [Assigned] (GEODE-2246) Invalid class cast in function execution

[Dan Smith (JIRA)]

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

Dan Smith reassigned GEODE-2246:


Assignee: (was: Michael Dodge)

> Invalid class cast in function execution
> 
>
> Key: GEODE-2246
> URL: https://issues.apache.org/jira/browse/GEODE-2246
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Michael Dodge
>
> In some situations (e.g., running a certain version of the native client 
> quickstarts) a ClassCastException is thrown inside ExecuteFunction66.run() at 
> line 391 of ExecuteFunction66.java:
> final DistributionManager newDM = (DistributionManager) dm;
> The variable dm is an instance of the interface 
> org.apache.geode.distributed.internal.DM. The class 
> org.apache.geode.distributed.internal.DistributionManager implements DM but 
> not all implementers of DM extend DistributionManager, e.g., 
> org.apache.geode.distributed.internal.LonerDistributionManager.



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

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

[Galen M O'Sullivan]

I think we should be presenting the current proposal as the API and message
structure, as would be laid out in an IDL. This way, we can experiment with
Protobuf, Thrift serialization,  for message structure without having to
exactly specify the message structure. This will make designing a protocol
easier and allow us to leverage existing serialization libraries. If we
ever get into a totally and manually specified binary protocol, charts of
binary representations will be useful, but for now I think using a library
that takes care of serialization for us will make our lives much easier.
I've made some changes (removing type data, removing RequestHeader and
ResponseHeader) that should make the wiki pages clearer.


On Thu, May 4, 2017 at 2:14 PM, Jacob Barrett  wrote:
> > One benefit of messageHeader with chunk is that, it gives us ability to
> > write different messages(multiplexing) on same socket. And if thread is
> > ready it can write its message. Though we are not there yet, but that
will
> > require for single socket async architecture.
> >
>
> I wouldn't tackle that at this layer. I would suggest adding a layer
> between the message and TCP that creates channels that are opaque to the
> message layer above. The message layer wouldn't know if it was talking to
> multiple sockets to the client or single socket with multiple channels.

Though we haven't really discussed it explicitly, the new protocol is
adding the correlationID in the expectation that at some point it will be
possible to execute requests out-of-order. One alternative to correlationID
if we had multiple channels would be to use one channel per message or set
of (ordered) messages. This would be a bit expensive if we used separate
sockets for each, but if we had channels built into the protocol, it would
be fine. The other use of correlationID might be for retries or to check up
on a message after some issue leading to a disconnect. However, we have the
EventID for that.

As far as I know, we don't have the async, out-of-order functionality yet.
I believe that in the current protocol, messages are ordered and
synchronous -- they only happen in the order they're sent, and each
operation blocks for the previous one to finish (though you could use
multiple connections to get similar functionality).

Galen

On Mon, May 8, 2017 at 2:55 PM, Ernest Burghardt 
wrote:

> +1 William, an even better example - that kind of representation will make
> it so much better/easier for geode users to implement against, regardless
> of language.
>
> On Mon, May 8, 2017 at 2:48 PM, William Markito Oliveira <
> william.mark...@gmail.com> wrote:
>
> > +1
> >
> > I think I've shared this before, but Kafka also has good (tabular)
> > representation for messages on their protocol.
> >
> > - https://kafka.apache.org/protocol#protocol_messages
> > - https://kafka.apache.org/protocol#protocol_message_sets
> >
> > On Mon, May 8, 2017 at 4:44 PM, Ernest Burghardt 
> > wrote:
> >
> > > Hello Geodes!
> > >
> > > Good discussion on what/how the messages will be/handled once a
> > connection
> > > is established.
> > >
> > > +1 to a simple initial handshake to establish version/supported
> features
> > > that client/server will be communicating.
> > >
> > > From what I've seen so far in the proposal it is missing a definition
> for
> > > the "connection"/disconnect messages.
> > > - expected to see it here:
> > > https://cwiki.apache.org/confluence/display/GEODE/Generic+System+API
> > >
> > > From a protocol perspective, this is currently a pain point for the
> > > geode-native library.
> > >
> > > As Jake mentioned previously, having messages that are class-like and
> > have
> > > a singular job helps client developers by having an explicit protocol
> to
> > > follow.
> > >
> > >
> > > The basic case a developer is going to exercise is to
> connect/disconnect.
> > > How to do this should be straightforward from the start.
> > >
> > > Geode probably does not need a 7 Layer OSI stack, but it might make
> sense
> > > to have a couple layers:
> > >
> > > 1 - transport  (network socket)
> > > 2 - protocol   (version/features)
> > > 3 - messaging (do cluster work)
> > >
> > > e.g.
> > > client library opens a socket to the server (layer 1 - check)
> > > client/server perform handshake and the connection is OPEN (layer 2 -
> > > check)
> > > pipe is open for business, client/server do work freely (layer 3 -
> check)
> > >
> > > When this is sorted out I think a couple simple sequence or activity
> > > diagrams would be very helpful to the visual-spatial folks in the
> > > community.
> > >
> > >
> > > Best,
> > > Ernie
> > >
> > > ps.  one consideration for message definition might be to use a more
> > > tabular presentation of messages followed by any
> > > definitions/cross-referencing... this is an example from a CDMA
> > protocol I
> > > have worked with in the past
> > >
> > > Location assignment message
> 

[jira] [Commented] (GEODE-2907) Remove @Experimental tag from the Lucene module

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Remove @Experimental tag from the Lucene module
> ---
>
> Key: GEODE-2907
> URL: https://issues.apache.org/jira/browse/GEODE-2907
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
>
> Issue:
> Remove the @Experimental tag from the files in the Lucene module to prepare 
> Apache Geode for the next release.
> Also improve on the javadocs for the interfaces present in the Lucene module.



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

[GitHub] geode pull request #503: GEODE-2907: Removed @Experimental tag from the Luce...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2909) Fix 2 typos in Lucene integration docs

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2909:


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

GEODE-2909  CTR fix of 2 typos in Lucene documentation


> Fix 2 typos in Lucene integration docs
> --
>
> Key: GEODE-2909
> URL: https://issues.apache.org/jira/browse/GEODE-2909
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> The 2 typos to be fixed:
> - In the Java API Example subsection, {{RegionShortcut}} is misspelled as 
> {{RegionShutcut}}.
> - For consistency, add a period to the end of the description of {{gfsh 
> search lucene}} in the Gfsh API subsection.
> These typos are minor.  Fix them under a CTR (commit then review) process.



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

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

[Jared Stewart (JIRA)]

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

Jared Stewart updated GEODE-2883:
-
Fix Version/s: 1.2.0

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



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

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

[Jared Stewart (JIRA)]

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

Jared Stewart updated GEODE-2883:
-
Affects Version/s: 1.0.0-incubating
   1.1.0
   1.1.1

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



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2883:


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

GEODE-2883: Fix GFSH gc heap size output


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



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

[jira] [Created] (GEODE-2911) LocatorDUnitTest.testLeadAndCoordFailure

[Udo Kohlmeyer (JIRA)]

Udo Kohlmeyer created GEODE-2911:


 Summary: LocatorDUnitTest.testLeadAndCoordFailure
 Key: GEODE-2911
 URL: https://issues.apache.org/jira/browse/GEODE-2911
 Project: Geode
  Issue Type: Bug
  Components: locator
Reporter: Udo Kohlmeyer


java.lang.AssertionError: expected suspect processing initiated by TCPConduit

at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.geode.distributed.LocatorDUnitTest.testLeadAndCoordFailure(LocatorDUnitTest.java:856)
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.junit.runner.JUnitCore.run(JUnitCore.java:137)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at 
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
at 
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)




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

[jira] [Updated] (GEODE-2910) Declaring Object Types in Geode Without Using Client Unclear

[Michael Martell (JIRA)]

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

Michael Martell updated GEODE-2910:
---
Description: 
We had trouble passing objects to functions via the REST API because we had no 
objects registered. The only documentation we found for passing objects was 
[here|http://geode.apache.org/docs/guide/11/rest_apps/develop_rest_apps.html#topic_rbc_h25_m4]
 where it says:

"... the Item domain object must be in the CLASSPATH of all members receiving 
the function."

As a C# programmer, this is very confusing. Helpful to spell out that your C# 
class needs to have a Java equivalent loaded in the server. Also that the 
object type name includes the Java package name.

Adding the following simple example to the documentation would have been a 
great demonstration of how objects are registered.

This Java class is required to register the above Item object on the server:
{code}
package cheezypizza;

public class Item {
public int itemNo;
public String description;
public int quantity;
public float unitprice;
public double totalprice;
}
{code}

A script to register the objects:
{code}
# Build the jar
javac -classpath /mnt/c/gemfire/lib/\* -d ./out src/cheezypizza/*.java
cd out
jar cvMf functions.jar cheezypizza/*.class

# Copy jar to server
scp functions.jar $HOSTNAME:/home/user

# In gfsh, starting the server, specify --classpath=
start server --name=rest-server --start-rest-api=true --http-service-port=8080 
--classpath=/home/user/functions.jar
{code}

  was:
We had trouble passing objects to functions via the REST API because we had no 
objects registered. The only documentation we found for passing objects was 
here: 
http://geode.apache.org/docs/guide/11/rest_apps/develop_rest_apps.html#topic_rbc_h25_m4

where it says:

"... the Item domain object must be in the CLASSPATH of all members receiving 
the function."

As a C# programmer, this is very confusing. Helpful to spell out that your C# 
class needs to have a Java equivalent loaded in the server.


> Declaring Object Types in Geode Without Using Client Unclear
> 
>
> Key: GEODE-2910
> URL: https://issues.apache.org/jira/browse/GEODE-2910
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Michael Martell
>
> We had trouble passing objects to functions via the REST API because we had 
> no objects registered. The only documentation we found for passing objects 
> was 
> [here|http://geode.apache.org/docs/guide/11/rest_apps/develop_rest_apps.html#topic_rbc_h25_m4]
>  where it says:
> "... the Item domain object must be in the CLASSPATH of all members receiving 
> the function."
> As a C# programmer, this is very confusing. Helpful to spell out that your C# 
> class needs to have a Java equivalent loaded in the server. Also that the 
> object type name includes the Java package name.
> Adding the following simple example to the documentation would have been a 
> great demonstration of how objects are registered.
> This Java class is required to register the above Item object on the server:
> {code}
> package cheezypizza;
> public class Item {
> public int itemNo;
> public String description;
> public int quantity;
> public float unitprice;
> public double totalprice;
> }
> {code}
> A script to register the objects:
> {code}
> # Build the jar
> javac -classpath /mnt/c/gemfire/lib/\* -d ./out src/cheezypizza/*.java
> cd out
> jar cvMf functions.jar cheezypizza/*.class
> # Copy jar to server
> scp functions.jar $HOSTNAME:/home/user
> # In gfsh, starting the server, specify --classpath=
> start server --name=rest-server --start-rest-api=true 
> --http-service-port=8080 --classpath=/home/user/functions.jar
> {code}



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

Re: Review Request 59181: write a dunit test to prove soundex analyzer is easy to apply

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On May 11, 2017, 4:15 p.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59181/
> ---
> 
> (Updated May 11, 2017, 4:15 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and Dan Smith.
> 
> 
> Bugs: GEODE-11
> https://issues.apache.org/jira/browse/GEODE-11
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> wrote a dunit test with one of the filter class and confirm the minimum jars 
> to be added.
> 
> 
> Diffs
> -
> 
>   geode-lucene/build.gradle 8545200a4 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneQueriesIntegrationTest.java
>  9db0a5e3a 
>   gradle/dependency-versions.properties a9e3fdf46 
> 
> 
> Diff: https://reviews.apache.org/r/59181/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

[jira] [Commented] (GEODE-2812) Add API to get list of live locators

[ASF GitHub Bot (JIRA)]

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

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

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/475
  
I've merged this to the "develop" branch.  Somehow my merge did not include 
the comment I made that it closed this PR.  You can close it now.

Thanks for the contribution!


> Add API to get list of live locators
> 
>
> Key: GEODE-2812
> URL: https://issues.apache.org/jira/browse/GEODE-2812
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> There is a Geode cluster using a logical member group, and from the client, 
> the connection pool to the logical member group is connected using the 
> PoolFactory API at the timing when connection becomes necessary.
> At this time, even though the locator that was running at the initial 
> connection stops due to reasons such as regular maintenance etc., even if the 
> alternate locator is started before maintenance, I can not connect to the 
> locator in the static initial list.
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupA").create("pool1");
> # Geode cluster:start locator [ localhost:10335 ].
> # Geode cluster:stop locator [ localhost:10334 ].
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupB").create("pool2");
> Therefore, I would like to decide the connection destination based on the 
> live locator list of another logical member group.
> I added an API that can get the list of live locators from the Pool. Use the 
> API as follows:
> {code:java|borderStyle=solid}
> Pool pool = PoolManager.createFactory()
>   .addLocator("localhost", 10334)
>   .setSubscriptionEnabled(true).setServerGroup("GroupA")
>   .create("GroupAPool");
> List = pool.getLiveLocators();
> {code}
> {quote}
> Note:
> The list of live locators gets the result of the UpdateLocatorListTask 
> periodically running in AutoConnectionSourceImpl.
> Therefore, whether or not it is alive will cause a time lag, depending on the 
> task execution interval.
> Also, the result of ExplicitConnectionSourceImpl without using a locator is 
> always empty.
> {quote}



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

[jira] [Commented] (GEODE-2812) Add API to get list of live locators

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2812:


Commit 8239e6fd64e01827d6df78c3c62fc886337cc011 in geode's branch 
refs/heads/develop from [~masaki.yamakawa]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=8239e6f ]

GEODE-2812: Add API to get list of live locators

I fixed 'gradlew spotlessApply' to fix them.

*
geode-core/src/main/java/org/apache/geode/cache/client/internal/AutoConnectionSourceImpl.java
*
geode-core/src/test/java/org/apache/geode/cache/client/internal/AutoConnectionSourceDUnitTest.java


> Add API to get list of live locators
> 
>
> Key: GEODE-2812
> URL: https://issues.apache.org/jira/browse/GEODE-2812
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> There is a Geode cluster using a logical member group, and from the client, 
> the connection pool to the logical member group is connected using the 
> PoolFactory API at the timing when connection becomes necessary.
> At this time, even though the locator that was running at the initial 
> connection stops due to reasons such as regular maintenance etc., even if the 
> alternate locator is started before maintenance, I can not connect to the 
> locator in the static initial list.
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupA").create("pool1");
> # Geode cluster:start locator [ localhost:10335 ].
> # Geode cluster:stop locator [ localhost:10334 ].
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupB").create("pool2");
> Therefore, I would like to decide the connection destination based on the 
> live locator list of another logical member group.
> I added an API that can get the list of live locators from the Pool. Use the 
> API as follows:
> {code:java|borderStyle=solid}
> Pool pool = PoolManager.createFactory()
>   .addLocator("localhost", 10334)
>   .setSubscriptionEnabled(true).setServerGroup("GroupA")
>   .create("GroupAPool");
> List = pool.getLiveLocators();
> {code}
> {quote}
> Note:
> The list of live locators gets the result of the UpdateLocatorListTask 
> periodically running in AutoConnectionSourceImpl.
> Therefore, whether or not it is alive will cause a time lag, depending on the 
> task execution interval.
> Also, the result of ExplicitConnectionSourceImpl without using a locator is 
> always empty.
> {quote}



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

[jira] [Commented] (GEODE-2812) Add API to get list of live locators

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2812:


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

GEODE-2812: Add API to get list of live locators

There is a Geode cluster using a logical member group, and from the
client, the connection pool to the logical member group is connected
using the PoolFactory API at the timing when connection becomes
necessary.
At this time, even though the locator that was running at the initial
connection stops due to reasons such as regular maintenance etc., even
if the alternate locator is started before maintenance, I can not
connect to the locator in the static initial list.

1. Client side:PoolManager.createFactory().addLocator("localhost",
10334).setServerGroup("GroupA").create("pool1");
2. Geode cluster:start locator[localhost:10335].
3. Geode cluster:stop locator[localhost:10334].
4. Client side:PoolManager.createFactory().addLocator("localhost",
10334).setServerGroup("GroupB").create("pool2");

Therefore, I would like to decide the connection destination based on
the live locator list of another logical member group.
I added an API that can get the list of live locators from the Pool. Use
the API as follows:

Pool pool = PoolManager.createFactory()
  .addLocator("localhost", 10334)
  .setSubscriptionEnabled(true).setServerGroup("GroupA")
  .create("GroupAPool");

List = pool.getLiveLocators();

Note:
The list of live locators gets the result of the UpdateLocatorListTask
periodically running in AutoConnectionSourceImpl.
Therefore, whether or not it is alive will cause a time lag, depending
on the task execution interval.
Also, the result of ExplicitConnectionSourceImpl without using a locator
is always empty.


> Add API to get list of live locators
> 
>
> Key: GEODE-2812
> URL: https://issues.apache.org/jira/browse/GEODE-2812
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> There is a Geode cluster using a logical member group, and from the client, 
> the connection pool to the logical member group is connected using the 
> PoolFactory API at the timing when connection becomes necessary.
> At this time, even though the locator that was running at the initial 
> connection stops due to reasons such as regular maintenance etc., even if the 
> alternate locator is started before maintenance, I can not connect to the 
> locator in the static initial list.
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupA").create("pool1");
> # Geode cluster:start locator [ localhost:10335 ].
> # Geode cluster:stop locator [ localhost:10334 ].
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupB").create("pool2");
> Therefore, I would like to decide the connection destination based on the 
> live locator list of another logical member group.
> I added an API that can get the list of live locators from the Pool. Use the 
> API as follows:
> {code:java|borderStyle=solid}
> Pool pool = PoolManager.createFactory()
>   .addLocator("localhost", 10334)
>   .setSubscriptionEnabled(true).setServerGroup("GroupA")
>   .create("GroupAPool");
> List = pool.getLiveLocators();
> {code}
> {quote}
> Note:
> The list of live locators gets the result of the UpdateLocatorListTask 
> periodically running in AutoConnectionSourceImpl.
> Therefore, whether or not it is alive will cause a time lag, depending on the 
> task execution interval.
> Also, the result of ExplicitConnectionSourceImpl without using a locator is 
> always empty.
> {quote}



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

[jira] [Updated] (GEODE-2891) connect-timeout violation in C++ Native Client

[Gregory Vortman (JIRA)]

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

Gregory Vortman updated GEODE-2891:
---

Hi Jacob,
This is the first issue opened by me in any open source project.
Not sure I understand why the issue status is Resolved.
Understood I have to correct the description and to remove any Gemfire instance 
from there. Will do it shortly.
Please let me know how to proceed with the issues.

Thanks



> connect-timeout violation in C++ Native Client
> --
>
> Key: GEODE-2891
> URL: https://issues.apache.org/jira/browse/GEODE-2891
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Gregory Vortman
> Attachments: gemfire-connect-timeout-violation.docx
>
>
> 1.C++ native client doesn’t honour read-timeout-milli-sec in a consistent 
> way while connecting to a server
> 2.The lock on the connection pool has a very high granularity. Even if 
> the client can’t connect to one server, all other threads which are working 
> with totally different servers get affected by it



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

[jira] [Created] (GEODE-2910) Declaring Object Types in Geode Without Using Client Unclear

[Michael Martell (JIRA)]

Michael Martell created GEODE-2910:
--

 Summary: Declaring Object Types in Geode Without Using Client 
Unclear
 Key: GEODE-2910
 URL: https://issues.apache.org/jira/browse/GEODE-2910
 Project: Geode
  Issue Type: Improvement
  Components: docs
Reporter: Michael Martell


We had trouble passing objects to functions via the REST API because we had no 
objects registered. The only documentation we found for passing objects was 
here: 
http://geode.apache.org/docs/guide/11/rest_apps/develop_rest_apps.html#topic_rbc_h25_m4

where it says:

"... the Item domain object must be in the CLASSPATH of all members receiving 
the function."

As a C# programmer, this is very confusing. Helpful to spell out that your C# 
class needs to have a Java equivalent loaded in the server.



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

[jira] [Commented] (GEODE-265) Remove deprecated methods on Execution interface

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-265:
--

Github user deepakddixit commented on the issue:

https://github.com/apache/geode/pull/509
  
@metatype Thanks for review. I have removed withArgs related changes.


> Remove deprecated methods on Execution interface
> 
>
> Key: GEODE-265
> URL: https://issues.apache.org/jira/browse/GEODE-265
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>   Original Estimate: 5h
>  Remaining Estimate: 5h
>
> The Execution interface has a number of execute methods that have been 
> deprecated. It looks like these could be easily removed.



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

[jira] [Updated] (GEODE-2891) connect-timeout violation in C++ Native Client

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett updated GEODE-2891:

Fix Version/s: (was: 1.1.1)

> connect-timeout violation in C++ Native Client
> --
>
> Key: GEODE-2891
> URL: https://issues.apache.org/jira/browse/GEODE-2891
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Gregory Vortman
> Attachments: gemfire-connect-timeout-violation.docx
>
>
> 1.C++ native client doesn’t honour read-timeout-milli-sec in a consistent 
> way while connecting to a server
> 2.The lock on the connection pool has a very high granularity. Even if 
> the client can’t connect to one server, all other threads which are working 
> with totally different servers get affected by it



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

[jira] [Resolved] (GEODE-2897) Add a GitHub PR template

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-2897.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Add a GitHub PR template
> 
>
> Key: GEODE-2897
> URL: https://issues.apache.org/jira/browse/GEODE-2897
> Project: Geode
>  Issue Type: Improvement
>  Components: github
>Reporter: Anthony Baker
>Assignee: Anthony Baker
> Fix For: 1.2.0
>
>
> We should add a PR template to help guide new contributors.
> Here's a good example:
> https://github.com/apache/nifi/blob/master/.github/PULL_REQUEST_TEMPLATE.md



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

[jira] [Commented] (GEODE-2897) Add a GitHub PR template

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2897:


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

GEODE-2897 Add PR template for github


> Add a GitHub PR template
> 
>
> Key: GEODE-2897
> URL: https://issues.apache.org/jira/browse/GEODE-2897
> Project: Geode
>  Issue Type: Improvement
>  Components: github
>Reporter: Anthony Baker
>Assignee: Anthony Baker
>
> We should add a PR template to help guide new contributors.
> Here's a good example:
> https://github.com/apache/nifi/blob/master/.github/PULL_REQUEST_TEMPLATE.md



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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user ameybarve15 commented on the issue:

https://github.com/apache/geode/pull/505
  
Can I merge this PR ? 


> Incorrect debug log location in 
> AbstractGatewaySenderEventProcessor.processQueue() 
> ---
>
> Key: GEODE-2890
> URL: https://issues.apache.org/jira/browse/GEODE-2890
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jason Huynh
>Assignee: Amey Barve
>
> The following code snippet in processQueue() for AEQ's appears to be outside 
> of an if condition where we check to see if the node is primary still or not. 
>  This line prints for every event and I believe it should be inside the 
> previous if condition. 
> {noformat}
> if (qpr != null) {
>BucketRegion bucket = qpr.getDataStore().getLocalBucketById(bucketId);
>if (bucket == null || !bucket.getBucketAdvisor().isPrimary()) {
>  event.setPossibleDuplicate(true);
> //I think the debug log should be placed here?
>}
> }
> if (isDebugEnabled) {
>   logger.debug( "Bucket id: {} is no longer primary on this node. The event 
> {} will be dispatched from this node with possibleDuplicate set to true.", 
> bucketId, event);
> }
> {noformat}



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