[jira] [Assigned] (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 reassigned GEODE-2897:


Assignee: Anthony Baker

> 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] [Created] (GEODE-2897) Add a GitHub PR template

[Anthony Baker (JIRA)]

Anthony Baker created GEODE-2897:


 Summary: 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


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] [Resolved] (GEODE-2554) Geode incubator docs are still up

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-2554.
--
Resolution: Fixed

> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



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

[jira] [Commented] (GEODE-2554) Geode incubator docs are still up

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2554:


Commit 7ce9eabbc1b7f4f0caa73cb1c84917cfd9826c64 in geode-site's branch 
refs/heads/master from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=geode-site.git;h=7ce9eab ]

GEODE-2554 Fix comment style


> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



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

[jira] [Commented] (GEODE-2554) Geode incubator docs are still up

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2554:


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

GEODE-2554 Tweak rewrite rule


> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



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

[jira] [Commented] (GEODE-2554) Geode incubator docs are still up

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2554:


Commit 916e8e9d0325ff918a95b6959e71556d6dac2d8f in geode-site's branch 
refs/heads/master from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=geode-site.git;h=916e8e9 ]

GEODE-2554 Tweak rewrite rule


> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



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

[jira] [Commented] (GEODE-2554) Geode incubator docs are still up

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2554:


Commit f3831614c108e378987068c51f0e9abd4b03ad39 in geode-site's branch 
refs/heads/master from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=geode-site.git;h=f383161 ]

GEODE-2554 Ensure .htaccess is compiled by nanoc


> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



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

[jira] [Commented] (GEODE-2554) Geode incubator docs are still up

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2554:


Commit 47979164a22f4781f34836f04f7e6422272c4258 in geode-site's branch 
refs/heads/master from [~jmcallis...@pivotal.io]
[ https://git-wip-us.apache.org/repos/asf?p=geode-site.git;h=4797916 ]

GEODE-2554 Add htaccess file for docs redirect


> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



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

[jira] [Commented] (GEODE-2554) Geode incubator docs are still up

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2554:


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

GEODE-2554 Add redirect for latest version of docs


> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



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

[jira] [Commented] (GEODE-234) remove deprecated MirrorType class

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-234:
--

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/495
  
Thanks @dschneider-pivotal for the review.
Do you want CacheXML and dtd  changes part of this PR.


> remove deprecated MirrorType class
> --
>
> Key: GEODE-234
> URL: https://issues.apache.org/jira/browse/GEODE-234
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>
> All uses of MirrorType should be changed to use DataPolicy.REPLICATE.
> All apis that take it as a parameter or return it need to be deleted.
> The cache-9.0.xsd should also be changed to no longer have the "mirror-type" 
> region-attribute.



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

[GitHub] geode issue #495: GEODE-234: Removed deprecated MirrorType class and its usa...

[davinash]

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/495
  
Thanks @dschneider-pivotal for the review.
Do you want CacheXML and dtd  changes part of this PR.


---
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-2879) LonerDistributionManager's Shutdown not being called in close()

[nabarun (JIRA)]

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

nabarun resolved GEODE-2879.

Resolution: Fixed

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



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

[jira] [Resolved] (GEODE-2754) CI failure: WanAutoDiscoveryDUnitTest

[nabarun (JIRA)]

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

nabarun resolved GEODE-2754.

   Resolution: Fixed
Fix Version/s: 1.2.0

> CI failure: WanAutoDiscoveryDUnitTest
> -
>
> Key: GEODE-2754
> URL: https://issues.apache.org/jira/browse/GEODE-2754
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Bruce Schuchardt
>  Labels: CI
> Fix For: 1.2.0
>
>
> Two new tests in this class fail if the network happens to have a machine 
> named "unknown".
> {noformat}
> :geode-wan:distributedTest
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest > 
> testValidAndInvalidHostRemoteLocators FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest$$Lambda$1538/701582275.run
>  in VM 2 running on Host trout.gemstone.com with 8 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testRemoteLocators(WanAutoDiscoveryDUnitTest.java:645)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testValidAndInvalidHostRemoteLocators(WanAutoDiscoveryDUnitTest.java:622)
> Caused by:
> java.lang.AssertionError: expected:<1> but was:<2>
> 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.cache.wan.WANTestBase.verifyPool(WANTestBase.java:3446)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.lambda$testRemoteLocators$1f02559b$1(WanAutoDiscoveryDUnitTest.java:645)
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest > 
> testInvalidHostRemoteLocators FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest$$Lambda$1538/701582275.run
>  in VM 2 running on Host trout.gemstone.com with 8 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testRemoteLocators(WanAutoDiscoveryDUnitTest.java:645)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testInvalidHostRemoteLocators(WanAutoDiscoveryDUnitTest.java:611)
> Caused by:
> java.lang.AssertionError: expected null, but was: name=ln>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotNull(Assert.java:755)
> at org.junit.Assert.assertNull(Assert.java:737)
> at org.junit.Assert.assertNull(Assert.java:747)
> at 
> org.apache.geode.internal.cache.wan.WANTestBase.verifyPool(WANTestBase.java:3448)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.lambda$testRemoteLocators$1f02559b$1(WanAutoDiscoveryDUnitTest.java:645)
> {noformat}



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

[jira] [Commented] (GEODE-2662) Gfsh displays field value on wrong line!

[ASF GitHub Bot (JIRA)]

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

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

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/500
  
precheckin returns green across the board.


> Gfsh displays field value on wrong line!
> 
>
> Key: GEODE-2662
> URL: https://issues.apache.org/jira/browse/GEODE-2662
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Eitan Suez
>Assignee: Patrick Rhomberg
>
> scenario:
> start a locator, a server
> write a client that stores several records of a given type, using pdx 
> serialization
> modify the type in question by adding a field
> write one more record to gemfire, populating all fields, including the new 
> field
> invoke a gfsh query command "select * from /"
> the new field value will display always on the first line of the result set, 
> not on the line associated with the object it actually belongs to.
> example:
> Customer
>  firstName, lastName
> write a customer object:
>  John Doe
> now modify Customer, add telephoneNumber
>  write another customer object:
> Sam Smith, 512.333.
> now run:
> query --query="select c from /Customer c"
> will print:
> firstName | lastName | telephoneNumber
> - |  | ---
> John  | Doe  | 512.333.
> Sam   | Smith| null
> even though the query "select c from /Customer c where c.firstName = 'Sam'" 
> clearly shows the phone number is associated with sam.
> this bug has existed in gemfire at least since v8 and verified to still exist 
> in latest version 9.0.1



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

[GitHub] geode issue #500: GEODE-2662: Gfsh displays field value on wrong line ...

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/500
  
precheckin returns green across the board.


---
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-2662) Gfsh displays field value on wrong line!

[ASF GitHub Bot (JIRA)]

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

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

GitHub user PurelyApplied opened a pull request:

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

GEODE-2662: Gfsh displays field value on wrong line ...

... when receiving objects with missing fields.

DataCommandResult.buildTable refactored to scan for all necessary fields 
and build rows, padding with MISSING_VALUE as necessary.

Additionally, significant refactoring for readability.

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

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

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

https://github.com/apache/geode/pull/500.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #500






> Gfsh displays field value on wrong line!
> 
>
> Key: GEODE-2662
> URL: https://issues.apache.org/jira/browse/GEODE-2662
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Eitan Suez
>Assignee: Patrick Rhomberg
>
> scenario:
> start a locator, a server
> write a client that stores several records of a given type, using pdx 
> serialization
> modify the type in question by adding a field
> write one more record to gemfire, populating all fields, including the new 
> field
> invoke a gfsh query command "select * from /"
> the new field value will display always on the first line of the result set, 
> not on the line associated with the object it actually belongs to.
> example:
> Customer
>  firstName, lastName
> write a customer object:
>  John Doe
> now modify Customer, add telephoneNumber
>  write another customer object:
> Sam Smith, 512.333.
> now run:
> query --query="select c from /Customer c"
> will print:
> firstName | lastName | telephoneNumber
> - |  | ---
> John  | Doe  | 512.333.
> Sam   | Smith| null
> even though the query "select c from /Customer c where c.firstName = 'Sam'" 
> clearly shows the phone number is associated with sam.
> this bug has existed in gemfire at least since v8 and verified to still exist 
> in latest version 9.0.1



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

[jira] [Commented] (GEODE-2894) Review getEntry on Region

[Darrel Schneider (JIRA)]

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

Darrel Schneider commented on GEODE-2894:
-

Except for partitioned regions getEntry always returns a Region.Entry the 
describes the local, in process, cache state.
Region.Entry has an "isLocal" method with these javadocs:
{noformat}
/**
 * This method checks to see if the entry is in the in-process cache, or is 
in another process.
 * Only Regions with {@link DataPolicy#PARTITION} may return false in 
response to this query. A
 * non-local Entry will not reflect dynamic changes being made to the 
cache. For instance, the
 * result of getValue() will not change, even though the cache may have 
been updated for the
 * corresponding key. To see an updated snapshot of a non-local Entry, you 
must fetch the entry
 * from the Region again.
 */
public boolean isLocal();
{noformat}

> Review getEntry on Region
> -
>
> Key: GEODE-2894
> URL: https://issues.apache.org/jira/browse/GEODE-2894
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Fred Krone
>
> This needs to behave the same as .get()
> For example, on a RegionAttributeShortcut.PROXY
> .put will put on the server ... 
> but currently .entry is local only and will return null 
> .get will go to the server and get the value
> ACCEPTANCE
> WHEN Region.put(Object o) is used Region.get or Region.getEntry should return 
> as .get would



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

[jira] [Resolved] (GEODE-1728) SessionCachingFilter can create multiple sessions when requests are forwarded

[Dan Smith (JIRA)]

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

Dan Smith resolved GEODE-1728.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> SessionCachingFilter can create multiple sessions when requests are forwarded
> -
>
> Key: GEODE-1728
> URL: https://issues.apache.org/jira/browse/GEODE-1728
> Project: Geode
>  Issue Type: Bug
>  Components: docs, http session
>Reporter: Dan Smith
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> Our installer adds this configuration to the users web.xml file for the 
> session state replication:
> {code}
> 
> gemfire-session-filter
> /*
> FORWARD
> INCLUDE
> REQUEST
> ERROR
> 
> {code}
> This means that our filter will be applied to all incoming requests, and it 
> will be applied *again* if the request is forwarded to or includes another 
> servlet.
> We wrap the HttpServletRequest in our own RequestWrapper class. We have some 
> code that tries to prevent wrapping a request multiple times:
> {code}
> /**
>  * Early out if this isn't the right kind of request. We might see a
>  * RequestWrapper instance during a forward or include request.
>  */
> if (request instanceof RequestWrapper ||
> !(request instanceof HttpServletRequest)) {
>   LOG.debug("Handling already-wrapped request");
>   chain.doFilter(request, response);
>   return;
> }
> {code}
> Unfortunately, this check will not work if there are *other* filters in the 
> chain that also wrap the HttpServletRequest. That can result in us wrapping 
> the forwarded request in a new RequestWrapper that will create another 
> session.
> We should not add these  elements to the web.xml; it should  be 
> sufficient for our filter to intercept all requests initially. In addition, 
> we might want to enhance our check to see if we have already wrapped a 
> request to follow the chain of wrapped requests deeper. As long as other 
> filters wrap the request in a subclass of HttpServletRequestWrapper we should 
> be able to unwrap the request if needed.



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

[GitHub] geode pull request #500: GEODE-2662: Gfsh displays field value on wrong line...

[PurelyApplied]

GitHub user PurelyApplied opened a pull request:

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

GEODE-2662: Gfsh displays field value on wrong line ...

... when receiving objects with missing fields.

DataCommandResult.buildTable refactored to scan for all necessary fields 
and build rows, padding with MISSING_VALUE as necessary.

Additionally, significant refactoring for readability.

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

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

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

https://github.com/apache/geode/pull/500.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #500






---
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-1728) SessionCachingFilter can create multiple sessions when requests are forwarded

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> SessionCachingFilter can create multiple sessions when requests are forwarded
> -
>
> Key: GEODE-1728
> URL: https://issues.apache.org/jira/browse/GEODE-1728
> Project: Geode
>  Issue Type: Bug
>  Components: docs, http session
>Reporter: Dan Smith
>Assignee: Karen Smoler Miller
>
> Our installer adds this configuration to the users web.xml file for the 
> session state replication:
> {code}
> 
> gemfire-session-filter
> /*
> FORWARD
> INCLUDE
> REQUEST
> ERROR
> 
> {code}
> This means that our filter will be applied to all incoming requests, and it 
> will be applied *again* if the request is forwarded to or includes another 
> servlet.
> We wrap the HttpServletRequest in our own RequestWrapper class. We have some 
> code that tries to prevent wrapping a request multiple times:
> {code}
> /**
>  * Early out if this isn't the right kind of request. We might see a
>  * RequestWrapper instance during a forward or include request.
>  */
> if (request instanceof RequestWrapper ||
> !(request instanceof HttpServletRequest)) {
>   LOG.debug("Handling already-wrapped request");
>   chain.doFilter(request, response);
>   return;
> }
> {code}
> Unfortunately, this check will not work if there are *other* filters in the 
> chain that also wrap the HttpServletRequest. That can result in us wrapping 
> the forwarded request in a new RequestWrapper that will create another 
> session.
> We should not add these  elements to the web.xml; it should  be 
> sufficient for our filter to intercept all requests initially. In addition, 
> we might want to enhance our check to see if we have already wrapped a 
> request to follow the chain of wrapped requests deeper. As long as other 
> filters wrap the request in a subclass of HttpServletRequestWrapper we should 
> be able to unwrap the request if needed.



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

[jira] [Commented] (GEODE-1728) SessionCachingFilter can create multiple sessions when requests are forwarded

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1728:


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

GEODE-1728: Http session filter should not be applied to FORWARDS

The docs should not tell users to add apply the session filter to
FORWARD, INCLUDE, and ERROR dispatchers. It should just be the default,
REQUEST.

This closes #489


> SessionCachingFilter can create multiple sessions when requests are forwarded
> -
>
> Key: GEODE-1728
> URL: https://issues.apache.org/jira/browse/GEODE-1728
> Project: Geode
>  Issue Type: Bug
>  Components: docs, http session
>Reporter: Dan Smith
>Assignee: Karen Smoler Miller
>
> Our installer adds this configuration to the users web.xml file for the 
> session state replication:
> {code}
> 
> gemfire-session-filter
> /*
> FORWARD
> INCLUDE
> REQUEST
> ERROR
> 
> {code}
> This means that our filter will be applied to all incoming requests, and it 
> will be applied *again* if the request is forwarded to or includes another 
> servlet.
> We wrap the HttpServletRequest in our own RequestWrapper class. We have some 
> code that tries to prevent wrapping a request multiple times:
> {code}
> /**
>  * Early out if this isn't the right kind of request. We might see a
>  * RequestWrapper instance during a forward or include request.
>  */
> if (request instanceof RequestWrapper ||
> !(request instanceof HttpServletRequest)) {
>   LOG.debug("Handling already-wrapped request");
>   chain.doFilter(request, response);
>   return;
> }
> {code}
> Unfortunately, this check will not work if there are *other* filters in the 
> chain that also wrap the HttpServletRequest. That can result in us wrapping 
> the forwarded request in a new RequestWrapper that will create another 
> session.
> We should not add these  elements to the web.xml; it should  be 
> sufficient for our filter to intercept all requests initially. In addition, 
> we might want to enhance our check to see if we have already wrapped a 
> request to follow the chain of wrapped requests deeper. As long as other 
> filters wrap the request in a subclass of HttpServletRequestWrapper we should 
> be able to unwrap the request if needed.



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

[jira] [Commented] (GEODE-2754) CI failure: WanAutoDiscoveryDUnitTest

[ASF GitHub Bot (JIRA)]

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

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

Github user nabarunnag closed the pull request at:

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


> CI failure: WanAutoDiscoveryDUnitTest
> -
>
> Key: GEODE-2754
> URL: https://issues.apache.org/jira/browse/GEODE-2754
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Bruce Schuchardt
>  Labels: CI
>
> Two new tests in this class fail if the network happens to have a machine 
> named "unknown".
> {noformat}
> :geode-wan:distributedTest
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest > 
> testValidAndInvalidHostRemoteLocators FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest$$Lambda$1538/701582275.run
>  in VM 2 running on Host trout.gemstone.com with 8 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testRemoteLocators(WanAutoDiscoveryDUnitTest.java:645)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testValidAndInvalidHostRemoteLocators(WanAutoDiscoveryDUnitTest.java:622)
> Caused by:
> java.lang.AssertionError: expected:<1> but was:<2>
> 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.cache.wan.WANTestBase.verifyPool(WANTestBase.java:3446)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.lambda$testRemoteLocators$1f02559b$1(WanAutoDiscoveryDUnitTest.java:645)
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest > 
> testInvalidHostRemoteLocators FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest$$Lambda$1538/701582275.run
>  in VM 2 running on Host trout.gemstone.com with 8 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testRemoteLocators(WanAutoDiscoveryDUnitTest.java:645)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testInvalidHostRemoteLocators(WanAutoDiscoveryDUnitTest.java:611)
> Caused by:
> java.lang.AssertionError: expected null, but was: name=ln>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotNull(Assert.java:755)
> at org.junit.Assert.assertNull(Assert.java:737)
> at org.junit.Assert.assertNull(Assert.java:747)
> at 
> org.apache.geode.internal.cache.wan.WANTestBase.verifyPool(WANTestBase.java:3448)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.lambda$testRemoteLocators$1f02559b$1(WanAutoDiscoveryDUnitTest.java:645)
> {noformat}



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

[GitHub] geode pull request #492: GEODE-2754: Changed the name of unknown host

[nabarunnag]

Github user nabarunnag closed the pull request at:

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


---
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-2754) CI failure: WanAutoDiscoveryDUnitTest

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2754:


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

GEODE-2754: Changed the name of unknown host

* Assert failures occured if the network contained machines named 
"unknown" as the test function also named the unknown host as "unknown"
* This led to test to find multiple machines named "unknown" rather 
than one.
* Changed the name of the unknown host set by the test to be 
"unknownGeodeHostWanAutoDiscoveryDUnitTest"


> CI failure: WanAutoDiscoveryDUnitTest
> -
>
> Key: GEODE-2754
> URL: https://issues.apache.org/jira/browse/GEODE-2754
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Bruce Schuchardt
>  Labels: CI
>
> Two new tests in this class fail if the network happens to have a machine 
> named "unknown".
> {noformat}
> :geode-wan:distributedTest
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest > 
> testValidAndInvalidHostRemoteLocators FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest$$Lambda$1538/701582275.run
>  in VM 2 running on Host trout.gemstone.com with 8 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testRemoteLocators(WanAutoDiscoveryDUnitTest.java:645)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testValidAndInvalidHostRemoteLocators(WanAutoDiscoveryDUnitTest.java:622)
> Caused by:
> java.lang.AssertionError: expected:<1> but was:<2>
> 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.cache.wan.WANTestBase.verifyPool(WANTestBase.java:3446)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.lambda$testRemoteLocators$1f02559b$1(WanAutoDiscoveryDUnitTest.java:645)
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest > 
> testInvalidHostRemoteLocators FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest$$Lambda$1538/701582275.run
>  in VM 2 running on Host trout.gemstone.com with 8 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testRemoteLocators(WanAutoDiscoveryDUnitTest.java:645)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.testInvalidHostRemoteLocators(WanAutoDiscoveryDUnitTest.java:611)
> Caused by:
> java.lang.AssertionError: expected null, but was: name=ln>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotNull(Assert.java:755)
> at org.junit.Assert.assertNull(Assert.java:737)
> at org.junit.Assert.assertNull(Assert.java:747)
> at 
> org.apache.geode.internal.cache.wan.WANTestBase.verifyPool(WANTestBase.java:3448)
> at 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.lambda$testRemoteLocators$1f02559b$1(WanAutoDiscoveryDUnitTest.java:645)
> {noformat}



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

[GitHub] geode pull request #499: GEODE-2879: Shutdown() called from close() in Loner...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[jira] [Created] (GEODE-2896) ClassCastException in GMSMembershipManagerJUnitTest

[nabarun (JIRA)]

nabarun created GEODE-2896:
--

 Summary: ClassCastException in GMSMembershipManagerJUnitTest
 Key: GEODE-2896
 URL: https://issues.apache.org/jira/browse/GEODE-2896
 Project: Geode
  Issue Type: Bug
  Components: tests
Reporter: nabarun


{noformat}
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
 > testDirectChannelSendFailureDueToForcedDisconnect FAILED
java.lang.ClassCastException: 
org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast 
to org.apache.geode.distributed.internal.DistributionManager
at 
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at 
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureDueToForcedDisconnect(GMSMembershipManagerJUnitTest.java:343)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
 > testStartupEvents FAILED
java.lang.ClassCastException: 
org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast 
to org.apache.geode.distributed.internal.DistributionManager
at 
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at 
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testStartupEvents(GMSMembershipManagerJUnitTest.java:219)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
 > testSendToEmptyListIsRejected FAILED
java.lang.ClassCastException: 
org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast 
to org.apache.geode.distributed.internal.DistributionManager
at 
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at 
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testSendToEmptyListIsRejected(GMSMembershipManagerJUnitTest.java:177)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
 > testDirectChannelSendAllRecipients FAILED
java.lang.ClassCastException: 
org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast 
to org.apache.geode.distributed.internal.DistributionManager
at 
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at 
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendAllRecipients(GMSMembershipManagerJUnitTest.java:331)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
 > testDirectChannelSend FAILED
java.lang.ClassCastException: 
org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast 
to org.apache.geode.distributed.internal.DistributionManager
at 
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at 
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSend(GMSMembershipManagerJUnitTest.java:281)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
 > testDirectChannelSendFailureToOneRecipient FAILED
java.lang.ClassCastException: 
org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast 
to org.apache.geode.distributed.internal.DistributionManager
at 
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at 
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToOneRecipient(GMSMembershipManagerJUnitTest.java:294)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
 > testDirectChannelSendFailureToAll FAILED
java.lang.ClassCastException: 
org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast 
to org.apache.geode.distributed.internal.DistributionManager
at 
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at 
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToAll(GMSMembershipManagerJUnitTest.java:313)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
 > testSendMessage FAILED
java.lang.ClassCastException: 
org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast 
to org.apache.geode.distributed.internal.DistributionManager
at 
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at 

[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=16001799#comment-16001799
 ] 

ASF subversion and git services commented on GEODE-2876:


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

GEODE-2876: Revert 65821d1 due to broken tests


> 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] [Issue Comment Deleted] (GEODE-2518) Developer can pass Collections via REST API

[Anthony Baker (JIRA)]

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

Anthony Baker updated GEODE-2518:
-
Comment: was deleted

(was: Note: This came up today in my meeting with Humana regarding Lucene 
status. This is a showstopper issue for them (Anup and Christian Ceballos). 
They were looking for an update on status. FYI.)

> Developer can pass Collections via REST API
> ---
>
> Key: GEODE-2518
> URL: https://issues.apache.org/jira/browse/GEODE-2518
> Project: Geode
>  Issue Type: Wish
>  Components: rest (dev)
>Reporter: Addison
>
> Requesting that the Gemfire REST Api allow the passing of a collection in the 
> JSON payload.



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

[jira] [Commented] (GEODE-2518) Developer can pass Collections via REST API

[Diane Hardman (JIRA)]

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

Diane Hardman commented on GEODE-2518:
--

Note: This came up today in my meeting with Humana regarding Lucene status. 
This is a showstopper issue for them (Anup and Christian Ceballos). They were 
looking for an update on status. FYI.

> Developer can pass Collections via REST API
> ---
>
> Key: GEODE-2518
> URL: https://issues.apache.org/jira/browse/GEODE-2518
> Project: Geode
>  Issue Type: Wish
>  Components: rest (dev)
>Reporter: Addison
>
> Requesting that the Gemfire REST Api allow the passing of a collection in the 
> JSON payload.



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

Broken: apache/geode#2523 (develop - 65821d1)

[Travis CI]

Build Update for apache/geode
-

Build: #2523
Status: Broken

Duration: 10 minutes and 38 seconds
Commit: 65821d1 (develop)
Author: Jared Stewart
Message: GEODE-2876: Add logging to diagnose CI failure

View the changeset: 
https://github.com/apache/geode/compare/5a1b06210d75...65821d1ea3e1

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/230130983?utm_source=email_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Re: Revert gradle upgrade

[Bruce Schuchardt]

The "eclipse" target fails, too.

Le 5/8/2017 à 3:32 PM, Kirk Lund a écrit :

I want to revert the gradle upgrade because it breaks IntelliJ and the idea
gradle task. Please let me know if you have a problem with this.

PS: Please be prepared to help me if you vote against me reverting the
upgrade ;) I really want to be able to work again. Thanks!

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

[ASF GitHub Bot (JIRA)]

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

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

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode-native/pull/95
  
@pivotal-jbarrett Thank you for your advice. Next time I'll rebase before 
PR.


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



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

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

[masaki-yamakawa]

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode-native/pull/95
  
@pivotal-jbarrett Thank you for your advice. Next time I'll rebase before 
PR.


---
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: Revert gradle upgrade

[Bruce Schuchardt]

+1 let's revert it

Le 5/8/2017 à 3:32 PM, Kirk Lund a écrit :

I want to revert the gradle upgrade because it breaks IntelliJ and the idea
gradle task. Please let me know if you have a problem with this.

PS: Please be prepared to help me if you vote against me reverting the
upgrade ;) I really want to be able to work again. Thanks!

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

[Lynn Gallinat (JIRA)]

Lynn Gallinat created GEODE-2895:


 Summary: 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


{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)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at 
org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 

Re: Revert gradle upgrade

[Udo Kohlmeyer]

+1 for revert... My build broke as well... after reverting, everything 
just worked :)



On 5/8/17 15:32, Kirk Lund wrote:

I want to revert the gradle upgrade because it breaks IntelliJ and the idea
gradle task. Please let me know if you have a problem with this.

PS: Please be prepared to help me if you vote against me reverting the
upgrade ;) I really want to be able to work again. Thanks!

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2738:


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

GEODE-2738: Corrected misspellibng of "occured" to "occurred"

This closes #435


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



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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


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



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2858:


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

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

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

This closes #397


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



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

[GitHub] geode pull request #397: GEODE-2858 - Add junit to try parsing of simple XML...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: [jira] [Created] (GEODE-2894) Review getEntry on Region

[Michael Stolz]

Wait, will .entry go to the server on a cache miss of a CACHING_PROXY?
I don't think so.

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

On Mon, May 8, 2017 at 5:24 PM, Fred Krone (JIRA)  wrote:

> Fred Krone created GEODE-2894:
> -
>
>  Summary: Review getEntry on Region
>  Key: GEODE-2894
>  URL: https://issues.apache.org/jira/browse/GEODE-2894
>  Project: Geode
>   Issue Type: Sub-task
> Reporter: Fred Krone
>
>
> This needs to behave the same as .get()
>
> For example, on a RegionAttributeShortcut.PROXY
>
> .put will put on the server ...
>
> but currently .entry is local only and will return null
> .get will go to the server and get the value
>
>
>
> ACCEPTANCE
> WHEN Region.put(Object o) is used Region.get or Region.getEntry should
> return as .get would
>
>
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>

[jira] [Commented] (GEODE-2554) Geode incubator docs are still up

[Joey McAllister (JIRA)]

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

Joey McAllister commented on GEODE-2554:


I think the only thing left to do for this ticket is to follow Anthony's advice 
to "override the install directive to prevent it from trying to run gradlew 
assemble." Can someone with Gradle Wrapper knowledge help with that?

> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



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

Review Request 59071: GEODE-2875 shutdown is taking as long as 20 seconds

[Bruce Schuchardt]

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

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


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


Repository: geode


Description
---

The band-aid fix for this problem was to reduce the wait-time on joining a 
thread sending shutdown messages.

This change set alters the membership manager, reviving the path of sending 
certain messages like ShutdownMessage over UDP instead of TCP/IP stream 
sockets.  This avenue doesn't block trying to form point-to-point connections 
so the join() can complete in a short amount of time.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
 e0c0ba29a5c74614d2430fb78d972e306a355845 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
 8ae66d0b6839cfbd46b479d896104f54fd11a68d 


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


Testing
---


Thanks,

Bruce Schuchardt

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

[Ernest Burghardt]

+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
> >
> > Field
> >
> > Length (bits)
> >
> > MessageID
> >
> > 8
> >
> > TransactionID
> >
> > 8
> >
> > LocationType
> >
> > 8
> >
> > LocationLength
> >
> > 8
> >
> > LocationValue
> >
> > 8 × LocationLength
> >
> >1.
> >
> >MessageID   The access network shall set this field to 0x05.
> >2.
> >
> >TransactionID  The access network shall increment this value for
> >each new LocationAssignment message sent.
> >
> >   LocationType   The access network shall set this field to
> the
> > type of the location as specified in Table
> >
> >
> >
> >
> >
> > [image: page144image36968] [image: page144image37392] [image:
> > page144image37976] [image: page144image38560] [image:
> > page144image38984] [image:
> > page144image39408]
> >
> >
> >
> >
> >
> >
> >
> > On Mon, May 8, 2017 at 7:48 AM, Jacob Barrett 
> wrote:
> >
> > > On Fri, May 5, 2017 at 2:09 PM Hitesh Khamesra 
> > > wrote:
> > >
> > > >
> > > > 0. In first phase we are not doing chunking/fragmentation. And even
> > this
> > > > will be option for client.(
> > > > https://cwiki.apache.org/confluence/display/GEODE/
> > Message+Structure+and+
> > > Definition#MessageStructureandDefinition-Protocolnegotiation
> > > > )
> > > >
> > >
> > > I highly suggest initial handshake be more relaxed than specific
> "version
> > > number" or flags. Consider sending objects that indicate support for
> > > features or even a list of feature IDs. At connect server can send list
> > of
> > > feature IDs to the client. The client can respond with a set of feature
> > IDs
> > > it supports as well as any metadata associated with them, say default
> set
> > > of supported encodings.
> > >
> > >
> > > > 1. Are you refereeing websocket/spdy? But I think we are talking
> almost
> > > > same thing, may be push isPartialMessage flag with chunk
> > length(Anthony's
> > > > example below) ?
> > > >
> > >
> > > I am not sure what you mean here but if you are talking about layering
> a
> > > channel protocol handler then I guess yes. The point is that each of
> > these
> > > behaviors should be encapsulated in specific layers and not intermixed
> > with
> > > the message.
> > >
> > >
> > > > 2. That's the part of the problem. Even if you need to serialize the
> > > > "String", you need to write length first and then need to write
> > > serialized
> > > > utf bytes. We can implement chunked input stream and can de-serialize
> > the
> > > > object as it is coming (DataSerializable.fromData(ChunkedStream)).
> > > >
> > >
> > 

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

[William Markito Oliveira]

+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
>
> Field
>
> Length (bits)
>
> MessageID
>
> 8
>
> TransactionID
>
> 8
>
> LocationType
>
> 8
>
> LocationLength
>
> 8
>
> LocationValue
>
> 8 × LocationLength
>
>1.
>
>MessageID   The access network shall set this field to 0x05.
>2.
>
>TransactionID  The access network shall increment this value for
>each new LocationAssignment message sent.
>
>   LocationType   The access network shall set this field to the
> type of the location as specified in Table
>
>
>
>
>
> [image: page144image36968] [image: page144image37392] [image:
> page144image37976] [image: page144image38560] [image:
> page144image38984] [image:
> page144image39408]
>
>
>
>
>
>
>
> On Mon, May 8, 2017 at 7:48 AM, Jacob Barrett  wrote:
>
> > On Fri, May 5, 2017 at 2:09 PM Hitesh Khamesra 
> > wrote:
> >
> > >
> > > 0. In first phase we are not doing chunking/fragmentation. And even
> this
> > > will be option for client.(
> > > https://cwiki.apache.org/confluence/display/GEODE/
> Message+Structure+and+
> > Definition#MessageStructureandDefinition-Protocolnegotiation
> > > )
> > >
> >
> > I highly suggest initial handshake be more relaxed than specific "version
> > number" or flags. Consider sending objects that indicate support for
> > features or even a list of feature IDs. At connect server can send list
> of
> > feature IDs to the client. The client can respond with a set of feature
> IDs
> > it supports as well as any metadata associated with them, say default set
> > of supported encodings.
> >
> >
> > > 1. Are you refereeing websocket/spdy? But I think we are talking almost
> > > same thing, may be push isPartialMessage flag with chunk
> length(Anthony's
> > > example below) ?
> > >
> >
> > I am not sure what you mean here but if you are talking about layering a
> > channel protocol handler then I guess yes. The point is that each of
> these
> > behaviors should be encapsulated in specific layers and not intermixed
> with
> > the message.
> >
> >
> > > 2. That's the part of the problem. Even if you need to serialize the
> > > "String", you need to write length first and then need to write
> > serialized
> > > utf bytes. We can implement chunked input stream and can de-serialize
> the
> > > object as it is coming (DataSerializable.fromData(ChunkedStream)).
> > >
> >
> > Right, and in this case the length is never the length of the string, it
> is
> > the length of the byte encoding of the string. This is not known until
> the
> > encoding is complete. So by chunking we can write the length of smaller
> > buffers (from buffer pools) as the length of that sequence of bytes, the
> > last chunk terminated with length 0. Each of those chunks can be based
> to a
> > UTF-8 to UTF-16 transcoder to create the String.
> >
> > -Jake
> >
>



-- 
~/William

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

[Ernest Burghardt]

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

Field

Length (bits)

MessageID

8

TransactionID

8

LocationType

8

LocationLength

8

LocationValue

8 × LocationLength

   1.

   MessageID   The access network shall set this field to 0x05.
   2.

   TransactionID  The access network shall increment this value for
   each new LocationAssignment message sent.

  LocationType   The access network shall set this field to the
type of the location as specified in Table





[image: page144image36968] [image: page144image37392] [image:
page144image37976] [image: page144image38560] [image:
page144image38984] [image:
page144image39408]







On Mon, May 8, 2017 at 7:48 AM, Jacob Barrett  wrote:

> On Fri, May 5, 2017 at 2:09 PM Hitesh Khamesra 
> wrote:
>
> >
> > 0. In first phase we are not doing chunking/fragmentation. And even this
> > will be option for client.(
> > https://cwiki.apache.org/confluence/display/GEODE/Message+Structure+and+
> Definition#MessageStructureandDefinition-Protocolnegotiation
> > )
> >
>
> I highly suggest initial handshake be more relaxed than specific "version
> number" or flags. Consider sending objects that indicate support for
> features or even a list of feature IDs. At connect server can send list of
> feature IDs to the client. The client can respond with a set of feature IDs
> it supports as well as any metadata associated with them, say default set
> of supported encodings.
>
>
> > 1. Are you refereeing websocket/spdy? But I think we are talking almost
> > same thing, may be push isPartialMessage flag with chunk length(Anthony's
> > example below) ?
> >
>
> I am not sure what you mean here but if you are talking about layering a
> channel protocol handler then I guess yes. The point is that each of these
> behaviors should be encapsulated in specific layers and not intermixed with
> the message.
>
>
> > 2. That's the part of the problem. Even if you need to serialize the
> > "String", you need to write length first and then need to write
> serialized
> > utf bytes. We can implement chunked input stream and can de-serialize the
> > object as it is coming (DataSerializable.fromData(ChunkedStream)).
> >
>
> Right, and in this case the length is never the length of the string, it is
> the length of the byte encoding of the string. This is not known until the
> encoding is complete. So by chunking we can write the length of smaller
> buffers (from buffer pools) as the length of that sequence of bytes, the
> last chunk terminated with length 0. Each of those chunks can be based to a
> UTF-8 to UTF-16 transcoder to create the String.
>
> -Jake
>

[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=16001594#comment-16001594
 ] 

ASF subversion and git services commented on GEODE-2876:


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

GEODE-2876: Add logging to diagnose CI 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] [Commented] (GEODE-2815) Incorrect Error Message in REST API docs for {region}/{key} HTTP.GET command

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2815:


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

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


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



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

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

[asfgit]

Github user asfgit closed the pull request at:

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


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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


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



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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/493
  
Received a drive-by +1 from mmartell, the filer of the JIRA ticket.


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



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

[GitHub] geode issue #493: GEODE-2815 Incorrect Error Message in REST API docs for {r...

[davebarnes97]

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/493
  
Received a drive-by +1 from mmartell, the filer of the JIRA ticket.


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

[jira] [Created] (GEODE-2894) Review getEntry on Region

[Fred Krone (JIRA)]

Fred Krone created GEODE-2894:
-

 Summary: Review getEntry on Region
 Key: GEODE-2894
 URL: https://issues.apache.org/jira/browse/GEODE-2894
 Project: Geode
  Issue Type: Sub-task
Reporter: Fred Krone


This needs to behave the same as .get()

For example, on a RegionAttributeShortcut.PROXY

.put will put on the server ... 

but currently .entry is local only and will return null 
.get will go to the server and get the value



ACCEPTANCE
WHEN Region.put(Object o) is used Region.get or Region.getEntry should return 
as .get would





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

[jira] [Resolved] (GEODE-2776) The version tag on client event is not updated when an entry is added to server using load operation.

[Anilkumar Gingade (JIRA)]

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

Anilkumar Gingade resolved GEODE-2776.
--
Resolution: Fixed

> The version tag on client event is not updated when an entry is added to 
> server using load operation.
> -
>
> Key: GEODE-2776
> URL: https://issues.apache.org/jira/browse/GEODE-2776
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Anilkumar Gingade
> Fix For: 1.2.0
>
>
> When client does a get() which results in adding an entry by calling loader 
> on server side, the client event returned back is not updated with the 
> version tag that is created with the new entry on server. This results in 
> client having a different version tag than the server side entry. If client 
> has registered event, and is concurrently updating the entry (from get() call 
> and an register-event from server), it could result in data consistency 
> between client and server.
> Scenario 1:
> On Server invalidate happens, and the event is added to client queue.
> Client does get()
> On Server, the get() triggers load + put on server. And the response is sent 
> back.
> Client gets the result from get() (which is newer) and applies to its cache.
> Client gets invalid event (older than get), and it applies the event to the 
> cache (this is supposed to be conflated, but due to this bug its not 
> conflated).
> At the end server has valid entry in the cache but client has invalid entry.
> On Server: INVALID (First), Get(From Client, LOAD+PUT) (later)
> On Client: GET(), PUT using Get Response(), INVALID (old)
> Scenario 2:
> Client does get()
> On Server, the get() triggers load + put on server. And the response is sent 
> back.
> On Server invalidate happens, and the event is added to client queue.
> Client gets invalid event, and it applies the event to the cache.
> Client gets the result from get() (which is older than invalidate) and 
> applies to its cache (this is supposed to be conflated, but due to this bug 
> its not conflated).
> At the end server has invalid entry in the cache but client has valid entry 
> (old value).
> On Server: Get(From Client, LOAD+PUT), INVALID (later)
> On Client: GET() (new), INVALID (old), PUT using Get Response().



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

Re: Review Request 59040: when advisor cannot found target nodes for bucket id, should double check if the member is offline

[Xiaojian Zhou]

Yes, PartitionOfflineException is the expected behavior.

On Mon, May 8, 2017 at 11:32 AM, Barry Oglesby  wrote:

>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59040/#review174209
> ---
>
>
>
>
> geode-core/src/main/java/org/apache/geode/internal/cache/execute/
> FunctionExecutionNodePruner.java
> Lines 63 (patched)
> 
>
> What happens in the persistent case? Does it throw a
> PartitionOfflineException?
>
>
> - Barry Oglesby
>
>
> On May 7, 2017, 5:47 p.m., xiaojian zhou wrote:
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/59040/
> > ---
> >
> > (Updated May 7, 2017, 5:47 p.m.)
> >
> >
> > Review request for geode, Barry Oglesby and Dan Smith.
> >
> >
> > Bugs: GEODE-2824
> > https://issues.apache.org/jira/browse/GEODE-2824
> >
> >
> > Repository: geode
> >
> >
> > Description
> > ---
> >
> > This is a race condition. When a member is offline (in redundentcopy=0
> case), an earlier check will found that. But if it passed the check, the
> code will enter a retry loop to ask advisor to give the target node.
> Finally the advisor will return an empty list of member. Then the code will
> screw up and throw the "No target node found" exception.
> >
> > The fix is: when the empty list is return, double check if target node
> is offline.
> >
> >
> > Diffs
> > -
> >
> >   geode-core/src/main/java/org/apache/geode/internal/cache/execute/
> FunctionExecutionNodePruner.java 18700a75d
> >
> >
> > Diff: https://reviews.apache.org/r/59040/diff/1/
> >
> >
> > Testing
> > ---
> >
> >
> > Thanks,
> >
> > xiaojian zhou
> >
> >
>
>

[jira] [Commented] (GEODE-2554) Geode incubator docs are still up

[ASF GitHub Bot (JIRA)]

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

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

Github user metatype commented on the issue:

https://github.com/apache/geode-site/pull/2
  
Whoops, you're right.  Ok, let's just do the latest -> 11 rule.


> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



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

[GitHub] geode-site issue #2: GEODE-2554 Add htaccess file for docs redirect

[metatype]

Github user metatype commented on the issue:

https://github.com/apache/geode-site/pull/2
  
Whoops, you're right.  Ok, let's just do the latest -> 11 rule.


---
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-2554) Geode incubator docs are still up

[ASF GitHub Bot (JIRA)]

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

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

Github user joeymcallister commented on the issue:

https://github.com/apache/geode-site/pull/2
  
@metatype Thanks for looking at the Travis issue.

I get what you're saying with the second RewriteRule, but my concern is 
that it also would impact directories that shouldn't be impacted, like `11`, 
`10`, and soon `12`. In other words, it would redirect `/guide/11/` to 
`/guide/11/11/`.

I spent the past couple of weeks submitting to Google's My Removal Requests 
page every search result pointing to `/docs/guide/...`. There may be a few 
stragglers, but Google should zap them when it eventually re-crawls the Geode 
site. Not creating a redirect to the files at `guide/` might cause some 
short-term strife with broken links from, for instance, the wiki, but I think 
the impact will be minimal and may be remedied by fixing the broken links to 
point to the new `guide/latest/` locations.

I _could_ create redirects for each of the files and directories within 
`guide` that we want redirected to `latest`, but that seems more like a bandage 
that eventually would need to be removed anyway.

What do you think?


> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



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

[GitHub] geode-site issue #2: GEODE-2554 Add htaccess file for docs redirect

[joeymcallister]

Github user joeymcallister commented on the issue:

https://github.com/apache/geode-site/pull/2
  
@metatype Thanks for looking at the Travis issue.

I get what you're saying with the second RewriteRule, but my concern is 
that it also would impact directories that shouldn't be impacted, like `11`, 
`10`, and soon `12`. In other words, it would redirect `/guide/11/` to 
`/guide/11/11/`.

I spent the past couple of weeks submitting to Google's My Removal Requests 
page every search result pointing to `/docs/guide/...`. There may be a few 
stragglers, but Google should zap them when it eventually re-crawls the Geode 
site. Not creating a redirect to the files at `guide/` might cause some 
short-term strife with broken links from, for instance, the wiki, but I think 
the impact will be minimal and may be remedied by fixing the broken links to 
point to the new `guide/latest/` locations.

I _could_ create redirects for each of the files and directories within 
`guide` that we want redirected to `latest`, but that seems more like a bandage 
that eventually would need to be removed anyway.

What do you think?


---
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-2352) Document that REST API requires two properties

[Dave Barnes (JIRA)]

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

Dave Barnes resolved GEODE-2352.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Document that REST API requires two properties
> --
>
> Key: GEODE-2352
> URL: https://issues.apache.org/jira/browse/GEODE-2352
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
> Fix For: 1.2.0
>
>
> Pulkit Chandra wrote in GEODE-2052:
> The REST api needs bind address property and http-service-port. Its not 
> called out clearly in the docs that they are *mandatory*. 
> [link to docs 
> section](http://geode.incubator.apache.org/docs/guide/rest_apps/setup_config.html)
> quote 
> ```
> To enable the developer REST API service in Apache Geode, set the 
> start-dev-rest-api Geode property to true when starting a data node using 
> either gfsh or the ServerLauncher API. Setting this property to true on a 
> data node will start up an embedded Jetty server and deploy the REST 
> developer API WAR file.
> ```
> We also found out that some of the gemfire.properties do not get applied when 
> supplied in geode.properties but rather have to be passed as command line 
> properties. e.g. enabling rest api.
> It would be nice to call that out clearly in docs.
> It should highlight that its necessary to have 2 more properties bind-address 
> and http-service-port defined to make it work.
> We would be happy to provide further details on this matter if needed.



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

[jira] [Commented] (GEODE-2352) Document that REST API requires two properties

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2352:


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

GEODE-2352 Document that REST API requires two properties


> Document that REST API requires two properties
> --
>
> Key: GEODE-2352
> URL: https://issues.apache.org/jira/browse/GEODE-2352
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Pulkit Chandra wrote in GEODE-2052:
> The REST api needs bind address property and http-service-port. Its not 
> called out clearly in the docs that they are *mandatory*. 
> [link to docs 
> section](http://geode.incubator.apache.org/docs/guide/rest_apps/setup_config.html)
> quote 
> ```
> To enable the developer REST API service in Apache Geode, set the 
> start-dev-rest-api Geode property to true when starting a data node using 
> either gfsh or the ServerLauncher API. Setting this property to true on a 
> data node will start up an embedded Jetty server and deploy the REST 
> developer API WAR file.
> ```
> We also found out that some of the gemfire.properties do not get applied when 
> supplied in geode.properties but rather have to be passed as command line 
> properties. e.g. enabling rest api.
> It would be nice to call that out clearly in docs.
> It should highlight that its necessary to have 2 more properties bind-address 
> and http-service-port defined to make it work.
> We would be happy to provide further details on this matter if needed.



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

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

[Eric Shu (JIRA)]

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

Eric Shu resolved GEODE-2882.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

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



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

[jira] [Updated] (GEODE-2776) The version tag on client event is not updated when an entry is added to server using load operation.

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-2776:
--
Fix Version/s: 1.2.0

> The version tag on client event is not updated when an entry is added to 
> server using load operation.
> -
>
> Key: GEODE-2776
> URL: https://issues.apache.org/jira/browse/GEODE-2776
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Anilkumar Gingade
> Fix For: 1.2.0
>
>
> When client does a get() which results in adding an entry by calling loader 
> on server side, the client event returned back is not updated with the 
> version tag that is created with the new entry on server. This results in 
> client having a different version tag than the server side entry. If client 
> has registered event, and is concurrently updating the entry (from get() call 
> and an register-event from server), it could result in data consistency 
> between client and server.
> Scenario 1:
> On Server invalidate happens, and the event is added to client queue.
> Client does get()
> On Server, the get() triggers load + put on server. And the response is sent 
> back.
> Client gets the result from get() (which is newer) and applies to its cache.
> Client gets invalid event (older than get), and it applies the event to the 
> cache (this is supposed to be conflated, but due to this bug its not 
> conflated).
> At the end server has valid entry in the cache but client has invalid entry.
> On Server: INVALID (First), Get(From Client, LOAD+PUT) (later)
> On Client: GET(), PUT using Get Response(), INVALID (old)
> Scenario 2:
> Client does get()
> On Server, the get() triggers load + put on server. And the response is sent 
> back.
> On Server invalidate happens, and the event is added to client queue.
> Client gets invalid event, and it applies the event to the cache.
> Client gets the result from get() (which is older than invalidate) and 
> applies to its cache (this is supposed to be conflated, but due to this bug 
> its not conflated).
> At the end server has invalid entry in the cache but client has valid entry 
> (old value).
> On Server: Get(From Client, LOAD+PUT), INVALID (later)
> On Client: GET() (new), INVALID (old), PUT using Get Response().



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2882:


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

GEODE-2882: Check if region is destroyed before throw IllegalStateException.


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



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

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

[Hitesh Khamesra]

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




geode-docs/rest_apps/setup_config.html.md.erb
Lines 84 (patched)


This looks good to me. ship it


- Hitesh Khamesra


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

Re: Review Request 59057: GEODE-2193 a member is kicked out immediately after joining

[Bruce Schuchardt]

> On May 8, 2017, 5:44 p.m., Hitesh Khamesra wrote:
> > geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
> > Line 830 (original)
> > 
> >
> > I think problem here is, we send shutdown message using Tcp layer. In 
> > that case, "receiver1" gets that shutdown message and pass that info to 
> > membership layer. Then "receiver1" becomes coordinator(legal coordinator) 
> > by removing current coordinator. Now if current coordinator sends new view 
> > then cluster just ignores that view, as cluster has new-view by "receiver1".

Thanks Hitesh.  I agree - I had removed the random number addition to the view 
number in becomeCoordinator last week and couldn't remember why I'd done that 
this morning so I reverted the change.  I'm going to put that back in because 
it makes it so that the prepared view isn't ignored.


- Bruce


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


On May 8, 2017, 5:23 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59057/
> ---
> 
> (Updated May 8, 2017, 5:23 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-2193
> https://issues.apache.org/jira/browse/GEODE-2193
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The previous fix for this ticket introduced a shutdown problem that caused 
> servers to pause waiting for ShutdownMessage to be sent to another server 
> that had already exited.  We reduced the pause time but this change set fixes 
> the problem by transmitting the message over UDP instead of TCP/IP stream 
> sockets.
> 
> Another change in GMSJoinLeave prepareView/sendView allows a membership 
> coordinator that is shutting down to complete the sending out of a new view 
> if it has already prepared the view when shutdown begins.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  e0c0ba29a5c74614d2430fb78d972e306a355845 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
>  8ae66d0b6839cfbd46b479d896104f54fd11a68d 
>   geode-core/src/main/java/org/apache/geode/internal/util/PluckStacks.java 
> 357812a6ec0cb09a88fa727a4bf828f18794264d 
> 
> 
> Diff: https://reviews.apache.org/r/59057/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin plus 1000 runs of the test that was hitting this issue at least 4% 
> of the time
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

[jira] [Updated] (GEODE-2893) Add containsKeyOnServer and containsValueOnServer to Region

[Fred Krone (JIRA)]

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

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

containsKeyOnServer 
containsValueOnServer

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.

containsKeyOnServer 
containsValueOnServer

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

When a developer uses these methods then the result should be from the 
server-side. 



> Add containsKeyOnServer and containsValueOnServer to Region
> ---
>
> Key: GEODE-2893
> URL: https://issues.apache.org/jira/browse/GEODE-2893
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Fred Krone
>
> To lower confusion while also not breaking backwards compatibility Region 
> needs explicit "onServer" methods.
> containsKeyOnServer 
> containsValueOnServer
> 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] [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 
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.

  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.


> 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
>
> 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] [Updated] (GEODE-2893) Add containsKeyOnServer and containsValueOnServer to Region

[Fred Krone (JIRA)]

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

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

containsKeyOnServer 
containsValueOnServer

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

When a developer uses these methods then the result should be from the 
server-side. 


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



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

[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:
--
Summary: Add sizeOnServer and emptyOnServer to Region  (was: Add on 
sizeOnServer and emptyOnServer to Region)

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



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

[jira] [Created] (GEODE-2893) Add containsKeyOnServer and containsValueOnServer to Region

[Fred Krone (JIRA)]

Fred Krone created GEODE-2893:
-

 Summary: Add containsKeyOnServer and containsValueOnServer to 
Region
 Key: GEODE-2893
 URL: https://issues.apache.org/jira/browse/GEODE-2893
 Project: Geode
  Issue Type: Sub-task
  Components: regions
Reporter: Fred Krone






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

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

[Fred Krone (JIRA)]

Fred Krone created GEODE-2892:
-

 Summary: Add on 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


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.



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

[jira] [Commented] (GEODE-2554) Geode incubator docs are still up

[ASF GitHub Bot (JIRA)]

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

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

Github user metatype commented on the issue:

https://github.com/apache/geode-site/pull/2
  
I think the rules should be:

```
RewriteRule /guide/latest/(.*)$ /guide/11/$1 [R=303,NC,L]
RewriteRule /guide/(.*)$ /guide/11/$1 [R=303,NC,L]
```

You can check this at a site like http://htaccess.mwl.be on 
```

https://geode.apache.org/docs/guide/configuring/running/running_the_cacheserver.html

https://geode.apache.org/docs/guide/latest/configuring/running/running_the_cacheserver.html
```


> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



--
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=16001397#comment-16001397
 ] 

ASF GitHub Bot commented on GEODE-254:
--

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

https://github.com/apache/geode/pull/488#discussion_r115331529
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyRegion.java
 ---
@@ -388,7 +388,7 @@ public Set keySetOnServer() {
   public Set keys() {
--- End diff --

I think you want this old "keys()" implementation to now be "keySet()". The 
old "keySet" did not properly call preOp/postOp.


> 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 #488: GEODE-254: Removed deprecated Region.keys and Regio...

[dschneider-pivotal]

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

https://github.com/apache/geode/pull/488#discussion_r115331529
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyRegion.java
 ---
@@ -388,7 +388,7 @@ public Set keySetOnServer() {
   public Set keys() {
--- End diff --

I think you want this old "keys()" implementation to now be "keySet()". The 
old "keySet" did not properly call preOp/postOp.


---
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-site issue #2: GEODE-2554 Add htaccess file for docs redirect

[metatype]

Github user metatype commented on the issue:

https://github.com/apache/geode-site/pull/2
  
Not sure why travis is unhappy.  Perhaps we need to override the `install` 
directive to prevent it from trying to run `gradlew assemble`.



---
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 59057: GEODE-2193 a member is kicked out immediately after joining

[Hitesh Khamesra]

> On May 8, 2017, 5:44 p.m., Hitesh Khamesra wrote:
> >

How about sending pending joinRequest(new member) with shutdown message. And 
let new coordinator take care of it.


- Hitesh


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


On May 8, 2017, 5:23 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59057/
> ---
> 
> (Updated May 8, 2017, 5:23 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-2193
> https://issues.apache.org/jira/browse/GEODE-2193
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The previous fix for this ticket introduced a shutdown problem that caused 
> servers to pause waiting for ShutdownMessage to be sent to another server 
> that had already exited.  We reduced the pause time but this change set fixes 
> the problem by transmitting the message over UDP instead of TCP/IP stream 
> sockets.
> 
> Another change in GMSJoinLeave prepareView/sendView allows a membership 
> coordinator that is shutting down to complete the sending out of a new view 
> if it has already prepared the view when shutdown begins.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  e0c0ba29a5c74614d2430fb78d972e306a355845 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
>  8ae66d0b6839cfbd46b479d896104f54fd11a68d 
>   geode-core/src/main/java/org/apache/geode/internal/util/PluckStacks.java 
> 357812a6ec0cb09a88fa727a4bf828f18794264d 
> 
> 
> Diff: https://reviews.apache.org/r/59057/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin plus 1000 runs of the test that was hitting this issue at least 4% 
> of the time
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

[jira] [Updated] (GEODE-2851) REST API can not execute functions with dot in the function ID

[Michael Dodge (JIRA)]

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

Michael Dodge updated GEODE-2851:
-
Description: 
Following the examples at 
(.../developing/function_exec/function_execution.html) we created a function 
that returned the class name as the function ID. After deploying the JAR 
containing that function using gfsh, we could successfully execute that 
function via gfsh:
{code}
gfsh>execute function --id=cheezypizza.DeleteFunction
Execution summary

Member ID/Name  | Function Execution Result
--- | -
10.32.104.55(rest-server:1878):1025 | Hello, world!
{code}

However, executing that function via a POST to 
http://35.165.170.9:8080/gemfire-api/v1/functions/cheezypizza.DeleteFunction 
fails, apparently because it stops reading the function ID at the '.' given 
{color:red}Caused by: org.apache.geode.cache.execute.FunctionException: 
Function named cheezypizza is not registered to FunctionService{color}:
{code}
org.apache.geode.rest.internal.web.exception.GemfireRestException: Server has 
encountered error while executing the function!
at 
org.apache.geode.rest.internal.web.controllers.FunctionAccessController.execute(FunctionAccessController.java:223)
at 
org.apache.geode.rest.internal.web.controllers.FunctionAccessController$$FastClassBySpringCGLIB$$b1783d32.invoke()
at 
org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
at 
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at 
org.springframework.security.access.intercept.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:69)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at 
org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
at 
org.apache.geode.rest.internal.web.controllers.FunctionAccessController$$EnhancerBySpringCGLIB$$225e498c.execute()
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.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
at 
org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136)
at 
org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:114)
at 
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827)
at 
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738)
at 
org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:963)
at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:897)
at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
at 
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:872)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at 
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:821)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1685)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:317)
at 
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:127)
at 
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:91)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:115)
at 

Re: Review Request 59040: when advisor cannot found target nodes for bucket id, should double check if the member is offline

[Barry Oglesby]

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




geode-core/src/main/java/org/apache/geode/internal/cache/execute/FunctionExecutionNodePruner.java
Lines 63 (patched)


What happens in the persistent case? Does it throw a 
PartitionOfflineException?


- Barry Oglesby


On May 7, 2017, 5:47 p.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59040/
> ---
> 
> (Updated May 7, 2017, 5:47 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and Dan Smith.
> 
> 
> Bugs: GEODE-2824
> https://issues.apache.org/jira/browse/GEODE-2824
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This is a race condition. When a member is offline (in redundentcopy=0 case), 
> an earlier check will found that. But if it passed the check, the code will 
> enter a retry loop to ask advisor to give the target node. Finally the 
> advisor will return an empty list of member. Then the code will screw up and 
> throw the "No target node found" exception. 
> 
> The fix is: when the empty list is return, double check if target node is 
> offline.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/execute/FunctionExecutionNodePruner.java
>  18700a75d 
> 
> 
> Diff: https://reviews.apache.org/r/59040/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

GMSMembershipManagerJUnitTest failing consistently in precheckin

[Kirk Lund]

I don't see this test failing in the nightly build but it seems to fail
consistently for me in precheckin (last 6 precheckins). Any ideas what's
wrong? Is anyone already looking into this failure?

:geode-core:test

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testDirectChannelSendFailureDueToForcedDisconnect FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureDueToForcedDisconnect(GMSMembershipManagerJUnitTest.java:343)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testStartupEvents FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testStartupEvents(GMSMembershipManagerJUnitTest.java:219)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testSendToEmptyListIsRejected FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testSendToEmptyListIsRejected(GMSMembershipManagerJUnitTest.java:177)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testDirectChannelSendAllRecipients FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendAllRecipients(GMSMembershipManagerJUnitTest.java:331)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testDirectChannelSend FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSend(GMSMembershipManagerJUnitTest.java:281)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testDirectChannelSendFailureToOneRecipient FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToOneRecipient(GMSMembershipManagerJUnitTest.java:294)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testDirectChannelSendFailureToAll FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToAll(GMSMembershipManagerJUnitTest.java:313)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testSendMessage FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testSendMessage(GMSMembershipManagerJUnitTest.java:148)

3013 tests completed, 8 failed, 11 skipped
:geode-core:test FAILED

[jira] [Commented] (GEODE-234) remove deprecated MirrorType class

[Avinash Dongre (JIRA)]

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

Avinash Dongre commented on GEODE-234:
--

[~dschneider] 
I found following files have reference of 'mirror-type'

geode-docs/reference/topics/cache_xml.html.md.erb
geode-docs/reference/topics/client-cache.html.md.erb
geode-docs/reference/topics/gfe_cache_xml.html.md.erb

I am not sure how docs are generated, this may be safe to ignore.


> remove deprecated MirrorType class
> --
>
> Key: GEODE-234
> URL: https://issues.apache.org/jira/browse/GEODE-234
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>
> All uses of MirrorType should be changed to use DataPolicy.REPLICATE.
> All apis that take it as a parameter or return it need to be deleted.
> The cache-9.0.xsd should also be changed to no longer have the "mirror-type" 
> region-attribute.



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

Re: gradle upgrade has broken IntelliJ

[Kirk Lund]

In order to get "./gradlew idea" to work I have to revert both of these
commits. After reverting them, the idea gradle task works.

commit 21d4ab2cf1c897bded41c0426a32531e926b689c
Author: Mark Bretl 
Date:   Mon May 1 09:57:53 2017 -0700

GEODE-2708: Update Minimum Gradle Version To 3.4.1

commit 9ed9e329f89f09ff2d91e1de48f17c9bbbf54512
Author: Mark Bretl 
Date:   Sat Apr 8 12:11:19 2017 -0700

GEODE-2708: Update Gradle Wrapper To 3.4.1

Tested and Verified By: ./gradlew precheckin

On Mon, May 8, 2017 at 11:05 AM, Kirk Lund  wrote:

> Looks like other projects are seeing this or something similar. Anyone
> with more gradle expertise want to try and fix this?
>
> There's some mention of a workaround here: https://github.com/akhikhl/
> gretty/issues/306
>
> On Mon, May 8, 2017 at 11:00 AM, Kirk Lund  wrote:
>
>> Looks like it's geode-core:antlr dependency in both CLI gradlew and
>> within IntelliJ. Here's the full stack trace in gradlew:
>>
>> * Exception is:
>> org.gradle.api.tasks.TaskExecutionException: Execution failed for task
>> ':geode-core:ideaModule'.
>> at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskEx
>> ecuter.executeActions(ExecuteActionsTaskExecuter.java:84)
>> at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskEx
>> ecuter.execute(ExecuteActionsTaskExecuter.java:55)
>> at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExec
>> uter.execute(SkipUpToDateTaskExecuter.java:62)
>> at org.gradle.api.internal.tasks.execution.ValidatingTaskExecut
>> er.execute(ValidatingTaskExecuter.java:58)
>> at org.gradle.api.internal.tasks.execution.SkipEmptySourceFiles
>> TaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:88)
>> at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactS
>> tateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:46)
>> at org.gradle.api.internal.tasks.execution.SkipTaskWithNoAction
>> sExecuter.execute(SkipTaskWithNoActionsExecuter.java:51)
>> at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecut
>> er.execute(SkipOnlyIfTaskExecuter.java:54)
>> at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTas
>> kExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
>> at org.gradle.api.internal.tasks.execution.CatchExceptionTaskEx
>> ecuter.execute(CatchExceptionTaskExecuter.java:34)
>> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$Even
>> tFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:236)
>> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$Even
>> tFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:228)
>> at org.gradle.internal.Transformers$4.transform(Transformers.
>> java:169)
>> at org.gradle.internal.progress.DefaultBuildOperationExecutor.r
>> un(DefaultBuildOperationExecutor.java:106)
>> at org.gradle.internal.progress.DefaultBuildOperationExecutor.r
>> un(DefaultBuildOperationExecutor.java:61)
>> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$Even
>> tFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:228)
>> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$Even
>> tFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:215)
>> at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$Task
>> ExecutorWorker.processTask(AbstractTaskPlanExecutor.java:77)
>> at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$Task
>> ExecutorWorker.run(AbstractTaskPlanExecutor.java:58)
>> at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.proce
>> ss(DefaultTaskPlanExecutor.java:32)
>> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.exec
>> ute(DefaultTaskGraphExecuter.java:113)
>> at org.gradle.execution.SelectedTaskExecutionAction.execute(Sel
>> ectedTaskExecutionAction.java:37)
>> at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBui
>> ldExecuter.java:37)
>> at org.gradle.execution.DefaultBuildExecuter.access$000(
>> DefaultBuildExecuter.java:23)
>> at org.gradle.execution.DefaultBuildExecuter$1.proceed(
>> DefaultBuildExecuter.java:43)
>> at org.gradle.execution.DryRunBuildExecutionAction.execute(DryR
>> unBuildExecutionAction.java:32)
>> at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBui
>> ldExecuter.java:37)
>> at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBui
>> ldExecuter.java:30)
>> at org.gradle.initialization.DefaultGradleLauncher$RunTasksActi
>> on.execute(DefaultGradleLauncher.java:256)
>> at org.gradle.initialization.DefaultGradleLauncher$RunTasksActi
>> on.execute(DefaultGradleLauncher.java:253)
>> at org.gradle.internal.Transformers$4.transform(Transformers.
>> java:169)
>> at org.gradle.internal.progress.DefaultBuildOperationExecutor.r

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

[Kirk Lund]

Looks like AdminRegion isn't "a Region" -- it's some sort of snapshot of a
Region. I don't know anything more than you unfortunately.

On Mon, May 8, 2017 at 11:05 AM, Avinash Dongre  wrote:

> It looks like
> org.apache.geode.distributed.internal.ConsoleDistributionManagerDUnitTest
> >
> testApplications FAILED
> because of my changes in GEODE-254.
>
> Since it is marked as Flaky I just ignore it but after replacing
>
> assertEquals(2, root.keySet().size());
>
> with
>
> assertEquals(2, ((AdminRegion)root).keys().size());
>
> Test is passing again.
>
> I am failing to understand why there is special impl for keys in
> AdminRegion ?
>
> and If this is correct fix.
>
>
> Thanks
>
> Avinash
>
>
>
> On Mon, May 8, 2017 at 11:26 PM, Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
> > See 
> >
> > --
> > [...truncated 120.69 KB...]
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > at java.lang.Thread.run(Thread.java:745)
> > Caused by: org.apache.geode.cache.execute.FunctionException:
> > org.apache.geode.cache.CacheClosedException: The cache is closed.
> > at org.apache.geode.internal.cache.execute.
> > LocalResultCollectorImpl.setException(LocalResultCollectorImpl.java:187)
> > at org.apache.geode.internal.cache.execute.
> > PartitionedRegionFunctionResultSender.setException(
> > PartitionedRegionFunctionResultSender.java:381)
> > at org.apache.geode.internal.cache.execute.AbstractExecution.
> > handleException(AbstractExecution.java:587)
> > at org.apache.geode.internal.cache.execute.AbstractExecution.
> > executeFunctionLocally(AbstractExecution.java:358)
> > at org.apache.geode.internal.cache.execute.
> > AbstractExecution$1.run(AbstractExecution.java:275)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > at org.apache.geode.distributed.internal.DistributionManager.
> > runUntilShutdown(DistributionManager.java:625)
> > at org.apache.geode.distributed.internal.DistributionManager$
> > 9$1.run(DistributionManager.java:1071)
> > ... 1 more
> > Caused by: org.apache.geode.cache.CacheClosedException: The cache is
> > closed.
> > at org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.
> > generateCancelledException(GemFireCacheImpl.java:1519)
> > at org.apache.geode.CancelCriterion.checkCancelInProgress(
> > CancelCriterion.java:83)
> > at org.apache.geode.internal.cache.LocalRegion.
> > checkRegionDestroyed(LocalRegion.java:7656)
> > at org.apache.geode.internal.cache.LocalRegion.
> > checkReadiness(LocalRegion.java:2788)
> > at org.apache.geode.internal.cache.BucketRegion.
> > checkReadiness(BucketRegion.java:1371)
> > at org.apache.geode.internal.cache.LocalRegion.size(
> > LocalRegion.java:9140)
> > at org.apache.geode.internal.cache.LocalRegion.isEmpty(
> > LocalRegion.java:9176)
> > at org.apache.geode.internal.cache.BucketRegionQueue.
> > waitUntilFlushed(BucketRegionQueue.java:485)
> > at org.apache.geode.internal.cache.wan.parallel.
> > WaitUntilParallelGatewaySenderFlushedCoordinator$
> > WaitUntilBucketRegionQueueFlushedCallable.call(
> > WaitUntilParallelGatewaySenderFlushedCoordinator.java:131)
> > at org.apache.geode.internal.cache.wan.parallel.
> > WaitUntilParallelGatewaySenderFlushedCoordinator$
> > WaitUntilBucketRegionQueueFlushedCallable.call(
> > WaitUntilParallelGatewaySenderFlushedCoordinator.java:111)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > at org.apache.geode.distributed.internal.DistributionManager.
> > runUntilShutdown(DistributionManager.java:625)
> > at org.apache.geode.distributed.internal.DistributionManager$
> > 6$1.run(DistributionManager.java:952)
> > ... 1 more
> >
> > 300 tests completed, 1 failed
> > :geode-lucene:distributedTest FAILED
> > :geode-lucene:flakyTest
> > :geode-lucene:integrationTest
> > :geode-old-client-support:assemble
> > :geode-old-client-support:compileTestJava
> > :geode-old-client-support:processTestResources NO-SOURCE
> > :geode-old-client-support:testClasses
> > :geode-old-client-support:checkMissedTests
> > :geode-old-client-support:spotlessJavaCheck
> > :geode-old-client-support:spotlessCheck
> > :geode-old-client-support:test
> > :geode-old-client-support:check
> > 

[jira] [Updated] (GEODE-2839) Enhance OQL portions of REST API developer documentation

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra updated GEODE-2839:
---
Component/s: rest (dev)

> Enhance OQL portions of REST API developer documentation
> 
>
> Key: GEODE-2839
> URL: https://issues.apache.org/jira/browse/GEODE-2839
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, rest (dev)
>Reporter: Michael Dodge
>
> The documentation for querying has excellent coverage of OQL 
> (developing/query_additional/query_language_features.html) however it is 
> difficult to get to that coverage from the REST API developer documentation, 
> e.g., rest_apps/rest_queries.html, rest_apps/post_create_query.html.
> * Some functionality differs between ad hoc ("unnamed") queries and created 
> ("named") queries, in particular whether the "LIKE 'foo%'" construct is 
> supported, and those differences are not obvious.
> * Whilst OQL syntax is discussed in the REST API documentation, there are no 
> hyperlinks to the OQL documentation.
> * The REST API documentation contains a few example of OQL use yet the OQL 
> documentation has more complete examples.



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

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

[Avinash Dongre]

It looks like
org.apache.geode.distributed.internal.ConsoleDistributionManagerDUnitTest >
testApplications FAILED
because of my changes in GEODE-254.

Since it is marked as Flaky I just ignore it but after replacing

assertEquals(2, root.keySet().size());

with

assertEquals(2, ((AdminRegion)root).keys().size());

Test is passing again.

I am failing to understand why there is special impl for keys in AdminRegion ?

and If this is correct fix.


Thanks

Avinash



On Mon, May 8, 2017 at 11:26 PM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See 
>
> --
> [...truncated 120.69 KB...]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.CacheClosedException: The cache is closed.
> at org.apache.geode.internal.cache.execute.
> LocalResultCollectorImpl.setException(LocalResultCollectorImpl.java:187)
> at org.apache.geode.internal.cache.execute.
> PartitionedRegionFunctionResultSender.setException(
> PartitionedRegionFunctionResultSender.java:381)
> at org.apache.geode.internal.cache.execute.AbstractExecution.
> handleException(AbstractExecution.java:587)
> at org.apache.geode.internal.cache.execute.AbstractExecution.
> executeFunctionLocally(AbstractExecution.java:358)
> at org.apache.geode.internal.cache.execute.
> AbstractExecution$1.run(AbstractExecution.java:275)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at org.apache.geode.distributed.internal.DistributionManager.
> runUntilShutdown(DistributionManager.java:625)
> at org.apache.geode.distributed.internal.DistributionManager$
> 9$1.run(DistributionManager.java:1071)
> ... 1 more
> Caused by: org.apache.geode.cache.CacheClosedException: The cache is
> closed.
> at org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.
> generateCancelledException(GemFireCacheImpl.java:1519)
> at org.apache.geode.CancelCriterion.checkCancelInProgress(
> CancelCriterion.java:83)
> at org.apache.geode.internal.cache.LocalRegion.
> checkRegionDestroyed(LocalRegion.java:7656)
> at org.apache.geode.internal.cache.LocalRegion.
> checkReadiness(LocalRegion.java:2788)
> at org.apache.geode.internal.cache.BucketRegion.
> checkReadiness(BucketRegion.java:1371)
> at org.apache.geode.internal.cache.LocalRegion.size(
> LocalRegion.java:9140)
> at org.apache.geode.internal.cache.LocalRegion.isEmpty(
> LocalRegion.java:9176)
> at org.apache.geode.internal.cache.BucketRegionQueue.
> waitUntilFlushed(BucketRegionQueue.java:485)
> at org.apache.geode.internal.cache.wan.parallel.
> WaitUntilParallelGatewaySenderFlushedCoordinator$
> WaitUntilBucketRegionQueueFlushedCallable.call(
> WaitUntilParallelGatewaySenderFlushedCoordinator.java:131)
> at org.apache.geode.internal.cache.wan.parallel.
> WaitUntilParallelGatewaySenderFlushedCoordinator$
> WaitUntilBucketRegionQueueFlushedCallable.call(
> WaitUntilParallelGatewaySenderFlushedCoordinator.java:111)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at org.apache.geode.distributed.internal.DistributionManager.
> runUntilShutdown(DistributionManager.java:625)
> at org.apache.geode.distributed.internal.DistributionManager$
> 6$1.run(DistributionManager.java:952)
> ... 1 more
>
> 300 tests completed, 1 failed
> :geode-lucene:distributedTest FAILED
> :geode-lucene:flakyTest
> :geode-lucene:integrationTest
> :geode-old-client-support:assemble
> :geode-old-client-support:compileTestJava
> :geode-old-client-support:processTestResources NO-SOURCE
> :geode-old-client-support:testClasses
> :geode-old-client-support:checkMissedTests
> :geode-old-client-support:spotlessJavaCheck
> :geode-old-client-support:spotlessCheck
> :geode-old-client-support:test
> :geode-old-client-support:check
> :geode-old-client-support:build
> :geode-old-client-support:distributedTest
> :geode-old-client-support:flakyTest
> :geode-old-client-support:integrationTest
> :geode-old-versions:javadoc NO-SOURCE
> :geode-old-versions:javadocJar
> :geode-old-versions:sourcesJar
> :geode-old-versions:signArchives SKIPPED
> :geode-old-versions:assemble
> :geode-old-versions:compileTestJava NO-SOURCE
> :geode-old-versions:processTestResources NO-SOURCE
> 

Re: gradle upgrade has broken IntelliJ

[Kirk Lund]

Looks like other projects are seeing this or something similar. Anyone with
more gradle expertise want to try and fix this?

There's some mention of a workaround here:
https://github.com/akhikhl/gretty/issues/306

On Mon, May 8, 2017 at 11:00 AM, Kirk Lund  wrote:

> Looks like it's geode-core:antlr dependency in both CLI gradlew and within
> IntelliJ. Here's the full stack trace in gradlew:
>
> * Exception is:
> org.gradle.api.tasks.TaskExecutionException: Execution failed for task
> ':geode-core:ideaModule'.
> at org.gradle.api.internal.tasks.execution.
> ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.
> java:84)
> at org.gradle.api.internal.tasks.execution.
> ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:55)
> at org.gradle.api.internal.tasks.execution.
> SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62)
> at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.
> execute(ValidatingTaskExecuter.java:58)
> at org.gradle.api.internal.tasks.execution.
> SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecut
> er.java:88)
> at org.gradle.api.internal.tasks.execution.
> ResolveTaskArtifactStateTaskExecuter.execute(
> ResolveTaskArtifactStateTaskExecuter.java:46)
> at org.gradle.api.internal.tasks.execution.
> SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.
> java:51)
> at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.
> execute(SkipOnlyIfTaskExecuter.java:54)
> at org.gradle.api.internal.tasks.execution.
> ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.
> java:43)
> at org.gradle.api.internal.tasks.execution.
> CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$
> EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:236)
> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$
> EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:228)
> at org.gradle.internal.Transformers$4.transform(
> Transformers.java:169)
> at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(
> DefaultBuildOperationExecutor.java:106)
> at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(
> DefaultBuildOperationExecutor.java:61)
> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$
> EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:228)
> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$
> EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:215)
> at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$
> TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:77)
> at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$
> TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:58)
> at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(
> DefaultTaskPlanExecutor.java:32)
> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.
> execute(DefaultTaskGraphExecuter.java:113)
> at org.gradle.execution.SelectedTaskExecutionAction.execute(
> SelectedTaskExecutionAction.java:37)
> at org.gradle.execution.DefaultBuildExecuter.execute(
> DefaultBuildExecuter.java:37)
> at org.gradle.execution.DefaultBuildExecuter.access$
> 000(DefaultBuildExecuter.java:23)
> at org.gradle.execution.DefaultBuildExecuter$1.
> proceed(DefaultBuildExecuter.java:43)
> at org.gradle.execution.DryRunBuildExecutionAction.execute(
> DryRunBuildExecutionAction.java:32)
> at org.gradle.execution.DefaultBuildExecuter.execute(
> DefaultBuildExecuter.java:37)
> at org.gradle.execution.DefaultBuildExecuter.execute(
> DefaultBuildExecuter.java:30)
> at org.gradle.initialization.DefaultGradleLauncher$
> RunTasksAction.execute(DefaultGradleLauncher.java:256)
> at org.gradle.initialization.DefaultGradleLauncher$
> RunTasksAction.execute(DefaultGradleLauncher.java:253)
> at org.gradle.internal.Transformers$4.transform(
> Transformers.java:169)
> at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(
> DefaultBuildOperationExecutor.java:106)
> at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(
> DefaultBuildOperationExecutor.java:56)
> at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(
> DefaultGradleLauncher.java:175)
> at org.gradle.initialization.DefaultGradleLauncher.doBuild(
> DefaultGradleLauncher.java:119)
> at org.gradle.initialization.DefaultGradleLauncher.run(
> DefaultGradleLauncher.java:102)
> at org.gradle.launcher.exec.GradleBuildController.run(
> GradleBuildController.java:71)
> at org.gradle.tooling.internal.provider.
> 

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

[nabarun (JIRA)]

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

nabarun resolved GEODE-2881.

   Resolution: Fixed
Fix Version/s: 1.2.0

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



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

[GitHub] geode pull request #498: GEODE-2881: Wait for waitForFlushBeforeExecuteTextS...

[nabarunnag]

Github user nabarunnag closed the pull request at:

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


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

Build failed in Jenkins: Geode-nightly #829

[Apache Jenkins Server]

See 

--
[...truncated 120.69 KB...]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.geode.cache.execute.FunctionException: 
org.apache.geode.cache.CacheClosedException: The cache is closed.
at 
org.apache.geode.internal.cache.execute.LocalResultCollectorImpl.setException(LocalResultCollectorImpl.java:187)
at 
org.apache.geode.internal.cache.execute.PartitionedRegionFunctionResultSender.setException(PartitionedRegionFunctionResultSender.java:381)
at 
org.apache.geode.internal.cache.execute.AbstractExecution.handleException(AbstractExecution.java:587)
at 
org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:358)
at 
org.apache.geode.internal.cache.execute.AbstractExecution$1.run(AbstractExecution.java:275)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:625)
at 
org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1071)
... 1 more
Caused by: org.apache.geode.cache.CacheClosedException: The cache is closed.
at 
org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:1519)
at 
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at 
org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7656)
at 
org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2788)
at 
org.apache.geode.internal.cache.BucketRegion.checkReadiness(BucketRegion.java:1371)
at 
org.apache.geode.internal.cache.LocalRegion.size(LocalRegion.java:9140)
at 
org.apache.geode.internal.cache.LocalRegion.isEmpty(LocalRegion.java:9176)
at 
org.apache.geode.internal.cache.BucketRegionQueue.waitUntilFlushed(BucketRegionQueue.java:485)
at 
org.apache.geode.internal.cache.wan.parallel.WaitUntilParallelGatewaySenderFlushedCoordinator$WaitUntilBucketRegionQueueFlushedCallable.call(WaitUntilParallelGatewaySenderFlushedCoordinator.java:131)
at 
org.apache.geode.internal.cache.wan.parallel.WaitUntilParallelGatewaySenderFlushedCoordinator$WaitUntilBucketRegionQueueFlushedCallable.call(WaitUntilParallelGatewaySenderFlushedCoordinator.java:111)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:625)
at 
org.apache.geode.distributed.internal.DistributionManager$6$1.run(DistributionManager.java:952)
... 1 more

300 tests completed, 1 failed
:geode-lucene:distributedTest FAILED
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources NO-SOURCE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-old-versions:javadoc NO-SOURCE
:geode-old-versions:javadocJar
:geode-old-versions:sourcesJar
:geode-old-versions:signArchives SKIPPED
:geode-old-versions:assemble
:geode-old-versions:compileTestJava NO-SOURCE
:geode-old-versions:processTestResources NO-SOURCE
:geode-old-versions:testClasses UP-TO-DATE
:geode-old-versions:checkMissedTests NO-SOURCE
:geode-old-versions:spotlessJavaCheck
:geode-old-versions:spotlessCheck
:geode-old-versions:test NO-SOURCE
:geode-old-versions:check
:geode-old-versions:build
:geode-old-versions:distributedTest NO-SOURCE
:geode-old-versions:flakyTest NO-SOURCE
:geode-old-versions:integrationTest NO-SOURCE
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2881:


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

GEODE-2881: Wait for waitForFlushBeforeExecuteTextSearch to complete

* Test now waits for waitForFlushBeforeExecuteTextSearch initiated by 
the test hook.
* The test hook gets called when GII is requested.
* This task may hit CacheClosedException if the test get completed 
before the flush operations of GII


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



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

Re: Review Request 59057: GEODE-2193 a member is kicked out immediately after joining

[Hitesh Khamesra]

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




geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
Line 1865 (original), 1865 (patched)


I am not sure this will also helps as it is similar to real 
proplem(describe earlier), where receiver will become new coordinator. And that 
will create new view by removing current coordinator.


- Hitesh Khamesra


On May 8, 2017, 5:23 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59057/
> ---
> 
> (Updated May 8, 2017, 5:23 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-2193
> https://issues.apache.org/jira/browse/GEODE-2193
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The previous fix for this ticket introduced a shutdown problem that caused 
> servers to pause waiting for ShutdownMessage to be sent to another server 
> that had already exited.  We reduced the pause time but this change set fixes 
> the problem by transmitting the message over UDP instead of TCP/IP stream 
> sockets.
> 
> Another change in GMSJoinLeave prepareView/sendView allows a membership 
> coordinator that is shutting down to complete the sending out of a new view 
> if it has already prepared the view when shutdown begins.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  e0c0ba29a5c74614d2430fb78d972e306a355845 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
>  8ae66d0b6839cfbd46b479d896104f54fd11a68d 
>   geode-core/src/main/java/org/apache/geode/internal/util/PluckStacks.java 
> 357812a6ec0cb09a88fa727a4bf828f18794264d 
> 
> 
> Diff: https://reviews.apache.org/r/59057/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin plus 1000 runs of the test that was hitting this issue at least 4% 
> of the time
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

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

[xiaojian zhou (JIRA)]

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

xiaojian zhou updated GEODE-2824:
-
Fix Version/s: 1.2.0

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



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

Re: gradle upgrade has broken IntelliJ

[Kirk Lund]

Even the "idea" task in gradle fails:

$ ./gradlew idea
...
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':geode-core:ideaModule'.
> Cannot change dependencies of configuration ':geode-core:antlr' after it
has been included in dependency resolution.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.

BUILD FAILED

Total time: 6.515 secs

I think we should roll back the commit that upgraded gradle until someone
with more gradle+intellij knowledge can fix this for the rest of us.

On Mon, May 8, 2017 at 10:46 AM, Kirk Lund  wrote:

> Our recent gradle upgrade seems to have broken IntelliJ. I've tried
> refreshing from gradle. I've even tried deleting .idea and my IntelliJ
> output directory and rebuilding my IntelliJ project in a couple different
> ways.
>
> No matter what I do, it seems to be stuck and IntelliJ refuses to work
> now. I'm up-to-date with latest version of IntelliJ as well.
>
> The only info from IntelliJ is the following:
>
> Gradle 'geode' project refresh failed
> Error:Cannot change dependencies of configuration ':geode-core:antlr'
> after it has been included in dependency resolution.
>
> Anyone else seeing this? Anyone know how to fix this? It's completely
> blocking my ability to work right now.
>
>

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

[xiaojian zhou (JIRA)]

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

xiaojian zhou resolved GEODE-2824.
--
Resolution: Fixed

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

GitHub user nabarunnag opened a pull request:

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

GEODE-2879: Shutdown() called from close() in LonerDistributionManager

* LonerDistributionManager shutdown was not being called from close() 
method call.
* This resulted in the thread pool's threads to wait for 1 minute of 
inactivity for them to be killed.
* This resulted in an extra delay while test executions.
* shutdown called from close method

Potential reviewers
@upthewaterspout @jhuynh1 @gesterzhou @ladyVader @boglesby 

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2879

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

https://github.com/apache/geode/pull/499.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #499


commit 57ff93335a01d8ae49fb087a0cd299dbb426485a
Author: nabarun 
Date:   2017-05-05T23:28:17Z

GEODE-2879: Shutdown() called from close() in LonerDistributionManager

* LonerDistributionManager shutdown was not being called from close() 
method call.
* This resulted in the thread pool's threads to wait for 1 minute of 
inactivity for them to be killed.
* This resulted in an extra delay while test executions.
* shutdown called from close method




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



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

[GitHub] geode pull request #499: GEODE-2879: Shutdown() called from close() in Loner...

[nabarunnag]

GitHub user nabarunnag opened a pull request:

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

GEODE-2879: Shutdown() called from close() in LonerDistributionManager

* LonerDistributionManager shutdown was not being called from close() 
method call.
* This resulted in the thread pool's threads to wait for 1 minute of 
inactivity for them to be killed.
* This resulted in an extra delay while test executions.
* shutdown called from close method

Potential reviewers
@upthewaterspout @jhuynh1 @gesterzhou @ladyVader @boglesby 

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2879

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

https://github.com/apache/geode/pull/499.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #499


commit 57ff93335a01d8ae49fb087a0cd299dbb426485a
Author: nabarun 
Date:   2017-05-05T23:28:17Z

GEODE-2879: Shutdown() called from close() in LonerDistributionManager

* LonerDistributionManager shutdown was not being called from close() 
method call.
* This resulted in the thread pool's threads to wait for 1 minute of 
inactivity for them to be killed.
* This resulted in an extra delay while test executions.
* shutdown called from close method




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

[jira] [Updated] (GEODE-2878) If an exception occurs after retrieving an XAConnection from the ConnectionProvider but before returning it to the application, the GemFireTransactionDataSource doesn't r

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-2878:
--
Labels: storage_3  (was: )

> If an exception occurs after retrieving an XAConnection from the 
> ConnectionProvider but before returning it to the application, the 
> GemFireTransactionDataSource doesn't return it to the pool
> --
>
> Key: GEODE-2878
> URL: https://issues.apache.org/jira/browse/GEODE-2878
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Barry Oglesby
>  Labels: storage_3
>
> In my test, I have 5 threads inserting rows into a derby database.
> At first, as connections are being used and returned, the 
> {{activeConnections}} is updated correctly:
> {noformat}
> Thread-16: AbstractPoolCache.getPooledConnectionFromPool activeConnections=1
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=2
> Thread-17: AbstractPoolCache.getPooledConnectionFromPool activeConnections=3
> Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=4
> Thread-18: AbstractPoolCache.getPooledConnectionFromPool activeConnections=5
> Thread-16: AbstractPoolCache.returnPooledConnectionToPool activeConnections=4
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=3
> Thread-18: AbstractPoolCache.returnPooledConnectionToPool activeConnections=2
> Thread-17: AbstractPoolCache.returnPooledConnectionToPool activeConnections=1
> Thread-15: AbstractPoolCache.returnPooledConnectionToPool activeConnections=0
> {noformat}
> But, then if an exception occurs after retrieving the {{XAConnection}}, it is 
> not return to the {{ConnectionProvider}}.
> In my test, the exception occurs in 
> {{GemFireTransactionDataSource.registerTranxConnection}}:
> {noformat}
> java.lang.Exception: GemFireTransactionDataSource-registerTranxConnection(). 
> Exception in registering the XAResource with the Transaction.Exception 
> occurred= javax.transaction.SystemException: 
> GlobalTransaction::enlistResource::error while enlisting XAResource 
> org.apache.derby.client.am.XaException: XAER_RMFAIL : An error occurred 
> during a deferred connect reset and the connection has been terminated.
>   at 
> org.apache.geode.internal.datasource.GemFireTransactionDataSource.registerTranxConnection(GemFireTransactionDataSource.java:218)
>   at 
> org.apache.geode.internal.datasource.GemFireTransactionDataSource.getConnection(GemFireTransactionDataSource.java:127)
>   at TestServer.saveToDB(TestServer.java:177)
>   at TestServer.save(TestServer.java:154)
>   at TestServer.loadEntriesIntoDerby(TestServer.java:127)
>   at TestServer$1.run(TestServer.java:112)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is after the {{XAConnection}} has been retrieved from the 
> {{ConnectionProvider}} and the {{activeConnections}} incremented, but before 
> it has been returned to the application. Neither the 
> {{registerTranxConnection}} method nor its caller ({{getConnection}}) does 
> anything other than to throw the exception. The {{XAConnection}} is not 
> returned to the pool nor is the {{activeConnections}} decremented.
> Finally, if enough of these exceptions occur, the test stops because all 30 
> (default max) connections are in use. They aren't really in use, its just 
> that the activeConnections counter hasn't been properly maintained.
> {noformat}
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=28
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=29
> Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-16: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
> Thread-18: AbstractPoolCache.returnPooledConnectionToPool activeConnections=28
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=29
> Thread-17: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
> Thread-18: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-17: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
> Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> {noformat}
> It doesn't really matter what the exception is. If one occurs after 
> retrieving the {{XAConnection}}, it needs to be returned to the 
> {{ConnectionProvider}} or at the very least, the {{activeConnections}} must 
> be decremented.



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2824:


Commit 3f1482b689db67a764b1f6507d4482a45e4bd11f in geode's branch 
refs/heads/develop from zhouxh
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3f1482b ]

GEODE-2824: When advisor cannot found target nodes for bucket id, should double 
check if the member is offline.


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



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

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

[nabarun (JIRA)]

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

nabarun reopened GEODE-2879:


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



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

gradle upgrade has broken IntelliJ

[Kirk Lund]

Our recent gradle upgrade seems to have broken IntelliJ. I've tried
refreshing from gradle. I've even tried deleting .idea and my IntelliJ
output directory and rebuilding my IntelliJ project in a couple different
ways.

No matter what I do, it seems to be stuck and IntelliJ refuses to work now.
I'm up-to-date with latest version of IntelliJ as well.

The only info from IntelliJ is the following:

Gradle 'geode' project refresh failed
Error:Cannot change dependencies of configuration ':geode-core:antlr' after
it has been included in dependency resolution.

Anyone else seeing this? Anyone know how to fix this? It's completely
blocking my ability to work right now.