[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564525#comment-15564525
]
John Blum edited comment on GEODE-1986 at 10/11/16 5:24 AM:
Inappropriately set the "_Fix Version/s_". It would be nice if this were fixed
prior to the *1.0.0-incubating (GA)* release.
was (Author: jblum):
In appropriately set the "Fix Version/s". It would be nice if this were fixed
prior to the 1.0.0-incubating (GA) release.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564525#comment-15564525
]
John Blum commented on GEODE-1986:
--
In appropriately set the "Fix Version/s". It would be nice if this were fixed
prior to the 1.0.0-incubating (GA) release.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-1986:
-
Fix Version/s: (was: 1.0.0-incubating)
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564233#comment-15564233
]
John Blum edited comment on GEODE-1986 at 10/11/16 3:29 AM:
As the logic is currently implemented, there appears to be no way to disable
the _Cluster Configuration_ service in Geode, and CC is not valid in all
contexts/UCs, much like the {{auto-reconnect}} feature.
was (Author: jblum):
As the logic is currently implemented, there appears to be no way to disable
the _Cluster Configuration_ service in Geode, and CC is not valid in all
contexts/UCs.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.0.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564233#comment-15564233
]
John Blum edited comment on GEODE-1986 at 10/11/16 3:28 AM:
As the logic is currently implemented, there appears to be no way to disable
the _Cluster Configuration_ service in Geode, and CC is not valid in all
contexts/UCs.
was (Author: jblum):
As it the logic is currently implemented, there appears to be no way to disable
the Cluster Configuration service in Geode, and CC is not valid in all
contexts/UCs.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.0.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-1986:
-
Description:
A bug was introduced in Geode when the logic to fetch the Cluster Configuration
meta-data from the Locator in the cluster by a joining member was refactored
into it's own
[class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
causing the following issues...
1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
no longer *optional* (hence, _required_), which is both short sighted and too
restrictive, and will break existing [embedded Geode application] deployments,
particularly in situations where GemFire config, and especially, _Gfsh_ were
not used to configure the cluster, which will be true when users upgrade
existing clusters based on an earlier versions of Apache Geode (namely GemFire
< v7.0, once GemFire 9 is based on Apache Geode) and as well as _Spring_
applications.
This change is apparent from the removal of the [conditional check on the Geode
System property
(1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
which is no longer present [here
(2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
or possibly [here
(3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
2. This does not work in the embedded Locator case. If a user configures a
peer Cache using the following in his/her application...
{code:java}
... = new CacheFactory()
.set("name", "Example")
.set("start-locator", "localhost[10334]")
...
.create();
{code}
And another members joins, the logic in (2) above, will fail with...
{code:java}
Caused by: org.apache.geode.GemFireConfigException: cluster configuration
service not available
at
org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
at
org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
... 42 more
Caused by:
org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
Unable to retrieve cluster configuration from the locator.
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
at
org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
... 47 more
{code}
was:
A bug was introduced when the logic to fetch the Cluster Configuration
meta-data from the Locator in the cluster by a member was refactored into it's
own
[class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
causing the following issues...
1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
no longer *optional* (hence, _required_), which is both short sighted and too
restrictive, and will break existing [embedded Geode application] deployments,
particularly in situations where GemFire config, and especially, _Gfsh_ were
not used to configure the cluster, which will be true when users upgrade
existing clusters based on an earlier versions of Apache Geode (namely GemFire
< v7.0, once GemFire 9 is based on Apache Geode) and as well as _Spring_
applications.
This change is apparent from the removal of the [conditional check on the Geode
System property
(1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
which is no longer present [here
(2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
or possibly [here
(3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
2. This does not work in the embedded Locator case. If a user configures a
peer Cache using the following in his/her application...
{code:java}
... = new CacheFactory()
.set("name", "Example")
.set("start-locator", "localho
[jira] [Commented] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564311#comment-15564311
]
John Blum commented on GEODE-1986:
--
In order to reproduce this problem (manually), you can run the attached {{App}}
Java class. You must start 2 instances where the 2nd instance connects to the
first instance by way of a embedded Locator that runs in the first instance.
Run the first instance with the following command-line...
{code}
$java example.App -Dgemfire.name=Server1
-Dgemfire.start-locator=localhost[10334]
{code}
Then start the second instance with this command-line...
{code}
-Dgemfire.name=Server2 -Dgemfire.locators=localhost[10334]
{code}
Witness the problem!
This test case should be rather easy to implement in an automated test. I
actually caught this bug in SD Geode's test suite when upgrading the dependency
on Apache Geode to {{1.1.0-incubating-SNAPSHOT}}.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.0.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced when the logic to fetch the Cluster Configuration
> meta-data from the Locator in the cluster by a member was refactored into
> it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564297#comment-15564297
]
John Blum edited comment on GEODE-1986 at 10/11/16 3:20 AM:
Attached example Application ({{App.java}}) starting an embedded peer Cache
instance to illustrate the problem.
was (Author: jblum):
Example Application starting an embedded peer Cache instance to illustrate the
problem.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.0.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced when the logic to fetch the Cluster Configuration
> meta-data from the Locator in the cluster by a member was refactored into
> it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-1986:
-
Description:
A bug was introduced when the logic to fetch the Cluster Configuration
meta-data from the Locator in the cluster by a member was refactored into it's
own
[class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
causing the following issues...
1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
no longer *optional* (hence, _required_), which is both short sighted and too
restrictive, and will break existing [embedded Geode application] deployments,
particularly in situations where GemFire config, and especially, _Gfsh_ were
not used to configure the cluster, which will be true when users upgrade
existing clusters based on an earlier versions of Apache Geode (namely GemFire
< v7.0, once GemFire 9 is based on Apache Geode) and as well as _Spring_
applications.
This change is apparent from the removal of the [conditional check on the Geode
System property
(1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
which is no longer present [here
(2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
or possibly [here
(3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
2. This does not work in the embedded Locator case. If a user configures a
peer Cache using the following in his/her application...
{code:java}
... = new CacheFactory()
.set("name", "Example")
.set("start-locator", "localhost[10334]")
...
.create();
{code}
And another members joins, the logic in (2) above, will fail with...
{code:java}
Caused by: org.apache.geode.GemFireConfigException: cluster configuration
service not available
at
org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
at
org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
... 42 more
Caused by:
org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
Unable to retrieve cluster configuration from the locator.
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
at
org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
... 47 more
{code}
was:
A bug was introduced when the logic to fetch the Cluster Configuration
meta-data from the Locator in the cluster by a member was broken out into it is
own
[class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
causing the following issues...
1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
no longer *optional* (hence, _required_), which is both short sighted and too
restrictive, and will break existing (embedded application) deployments,
particularly in situations where GemFire config, and especially, _Gfsh_ were
not used to configure the cluster, which will be true when users upgrade
existing clusters based on an earlier versions of Geode (namely GemFire < v7.0)
and as well as Spring applications.
This change is apparent from the removal of the [conditional check on the Geode
System property
(1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
which is no longer present [here
(2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
or possibly [here
(3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
2. This does not work in the embedded Locator case. If a user configures a
peer Cache using the following in his/her application...
{code:java}
... = new CacheFactory()
.set("name", "Example")
.set("start-locator", "localhost[10334]")
...
.create();
{code}
And another members joins, the log
[jira] [Updated] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-1986:
-
Attachment: App.java
Example Application starting an embedded peer Cache instance to illustrate the
problem.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.0.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced when the logic to fetch the Cluster Configuration
> meta-data from the Locator in the cluster by a member was broken out into it
> is own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing (embedded application) deployments,
> particularly in situations where GemFire config, and especially, _Gfsh_ were
> not used to configure the cluster, which will be true when users upgrade
> existing clusters based on an earlier versions of Geode (namely GemFire <
> v7.0) and as well as Spring applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-1986:
-
Flags: Important
Labels: ClusterConfig ClusterConfigurationService (was: )
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.0.0-incubating
>
>
> A bug was introduced when the logic to fetch the Cluster Configuration
> meta-data from the Locator in the cluster by a member was broken out into it
> is own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing (embedded application) deployments,
> particularly in situations where GemFire config, and especially, _Gfsh_ were
> not used to configure the cluster, which will be true when users upgrade
> existing clusters based on an earlier versions of Geode (namely GemFire <
> v7.0) and as well as Spring applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564233#comment-15564233
]
John Blum edited comment on GEODE-1986 at 10/11/16 3:15 AM:
As it the logic is currently implemented, there appears to be no way to disable
the Cluster Configuration service in Geode, and CC is not valid in all
contexts/UCs.
was (Author: jblum):
As it is currently implemented, there appears to be no way to disable the
Cluster Configuration service, which is not valid in all contexts/UCs.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Fix For: 1.0.0-incubating
>
>
> A bug was introduced when the logic to fetch the Cluster Configuration
> meta-data from the Locator in the cluster by a member was broken out into it
> is own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing (embedded application) deployments,
> particularly in situations where GemFire config, and especially, _Gfsh_ were
> not used to configure the cluster, which will be true when users upgrade
> existing clusters based on an earlier versions of Geode (namely GemFire <
> v7.0) and as well as Spring applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1956) CI failure: LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate
[ https://issues.apache.org/jira/browse/GEODE-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564279#comment-15564279 ] ASF subversion and git services commented on GEODE-1956: Commit 71c6325ed3328cd94055ba3a8d427453fbaee5c5 in incubator-geode's branch refs/heads/feature/GEODE-1801 from zhouxh [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=71c6325 ] GEODE-1956: fix the race condition that cause the vm only hosts 1 primary bucket > CI failure: > LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate > - > > Key: GEODE-1956 > URL: https://issues.apache.org/jira/browse/GEODE-1956 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Bruce Schuchardt >Assignee: xiaojian zhou > Labels: CI > > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest$$Lambda$50/1718051859.run > in VM 0 running on Host cc2-rh6.gemstone.com with 4 VMs > at org.apache.geode.test.dunit.VM.invoke(VM.java:389) > at org.apache.geode.test.dunit.VM.invoke(VM.java:355) > at org.apache.geode.test.dunit.VM.invoke(VM.java:293) > at > org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate(LuceneQueriesPeerPRRedundancyDUnitTest.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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.i
[jira] [Commented] (GEODE-1914) Geode source code contains old version of gemfire dtds
[ https://issues.apache.org/jira/browse/GEODE-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564277#comment-15564277 ] ASF subversion and git services commented on GEODE-1914: Commit 952ab6fa2fa166225d7a7fbfeca9e24852402e38 in incubator-geode's branch refs/heads/feature/GEODE-1801 from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=952ab6f ] GEODE-1914 Removed old dtds from geode source code(kept 7.0 and above) Deteted old tests and updated test xmls to point 7.0 dtd > Geode source code contains old version of gemfire dtds > -- > > Key: GEODE-1914 > URL: https://issues.apache.org/jira/browse/GEODE-1914 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Hitesh Khamesra >Assignee: Hitesh Khamesra > Fix For: 1.0.0-incubating > > > Geode source contains old version of gemfire dtds that can be drop. That are > referred by tests as well . And we may need to remove or upgrade those tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1926) The function peekAhead function puts the queue key into peekedIDs even though it was not in the batch to be dispatched
[ https://issues.apache.org/jira/browse/GEODE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564280#comment-15564280 ] ASF subversion and git services commented on GEODE-1926: Commit 52ef094368b262f9f355ad582787c515c5e12abc in incubator-geode's branch refs/heads/feature/GEODE-1801 from [~nnag] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=52ef094 ] GEODE-1926: Removing the extra getObjectInSerialSenderQueue call * This was causing few tests to hang waiting for queues to drain. > The function peekAhead function puts the queue key into peekedIDs even though > it was not in the batch to be dispatched > --- > > Key: GEODE-1926 > URL: https://issues.apache.org/jira/browse/GEODE-1926 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: nabarun > > The function peekAhead peeks the serial sender queue and if its able to get > an object in the queue, returns the object to the peek function to be > dispatched and adds the key to the peekedIds list. > The peek function tries to make a heap copy of the object returned , but > conflation may have kicked in the object may have been removed - hence the > object will not be placed in the dispatch batch. > However now the size of the peeked Ids and dispatched batch do not match, > hence when the remove thread starts removing the elements from the key using > the keys in peekedIds and using the size of the dispatched batch, there will > be lingering objects in the queue because the size of dispatched batch is > less than Ids that were peeked. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1973) GMSAuthenticator needs to work in a locator without cache
[ https://issues.apache.org/jira/browse/GEODE-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564278#comment-15564278 ] ASF subversion and git services commented on GEODE-1973: Commit ebf41ce66125927175dbfcc496bf1be666b348d9 in incubator-geode's branch refs/heads/feature/GEODE-1801 from [~jinmeiliao] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=ebf41ce ] GEODE-1973: add more tests to cover GMSAuthenticator and SimpleSecurityManager * adding more tests > GMSAuthenticator needs to work in a locator without cache > - > > Key: GEODE-1973 > URL: https://issues.apache.org/jira/browse/GEODE-1973 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Jinmei Liao >Assignee: Jinmei Liao > > GMSAuthenticator needs to work in a locator without cache -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1801) nonSingleHopsCount cache-perf statistic is inaccurate
[ https://issues.apache.org/jira/browse/GEODE-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564263#comment-15564263 ] ASF subversion and git services commented on GEODE-1801: Commit 9b6c10bc2f433b36546e6f3c22f39d3b20d880b5 in incubator-geode's branch refs/heads/feature/GEODE-1801 from [~ukohlmeyer] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=9b6c10b ] GEODE-1801: Change the logic to increment NonSingleHopsCount > nonSingleHopsCount cache-perf statistic is inaccurate > - > > Key: GEODE-1801 > URL: https://issues.apache.org/jira/browse/GEODE-1801 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Bruce Schuchardt >Assignee: Udo Kohlmeyer > > While working on GEODE-1761 I noticed that this statistic is only updated if > the metadata for server partitioned-region bucket location is going to be > refreshed. The statistic should actually be incremented any time the servers > send a metadata refresh hint in their response. PutOp, DestroyOp, GetOp, etc > need to do this in their processResponse() methods and the current increments > of the stat in ClientMetadataService should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564233#comment-15564233
]
John Blum commented on GEODE-1986:
--
As it is currently implemented, there appears to be no way to disable the
Cluster Configuration service, which is not valid in all contexts/UCs.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Fix For: 1.0.0-incubating
>
>
> A bug was introduced when the logic to fetch the Cluster Configuration
> meta-data from the Locator in the cluster by a member was broken out into it
> is own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing (embedded application) deployments,
> particularly in situations where GemFire config, and especially, _Gfsh_ were
> not used to configure the cluster, which will be true when users upgrade
> existing clusters based on an earlier versions of Geode (namely GemFire <
> v7.0) and as well as Spring applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-1986:
-
Description:
A bug was introduced when the logic to fetch the Cluster Configuration
meta-data from the Locator in the cluster by a member was broken out into it is
own
[class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
causing the following issues...
1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
no longer *optional* (hence, _required_), which is both short sighted and too
restrictive, and will break existing (embedded application) deployments,
particularly in situations where GemFire config, and especially, _Gfsh_ were
not used to configure the cluster, which will be true when users upgrade
existing clusters based on an earlier versions of Geode (namely GemFire < v7.0)
and as well as Spring applications.
This change is apparent from the removal of the [conditional check on the Geode
System property
(1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
which is no longer present [here
(2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
or possibly [here
(3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
2. This does not work in the embedded Locator case. If a user configures a
peer Cache using the following in his/her application...
{code:java}
... = new CacheFactory()
.set("name", "Example")
.set("start-locator", "localhost[10334]")
...
.create();
{code}
And another members joins, the logic in (2) above, will fail with...
{code:java}
Caused by: org.apache.geode.GemFireConfigException: cluster configuration
service not available
at
org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
at
org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
... 42 more
Caused by:
org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
Unable to retrieve cluster configuration from the locator.
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
at
org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
... 47 more
{code}
was:
A bug was introduced when the logic to fetch the Cluster Configuration
meta-data from the Locator in the cluster by a member was broken out into it is
own
[class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
causing the following issues...
1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
no longer *optional* (hence, _required_), which is both short sighted and too
restrictive, and will break existing (embedded application) deployments,
particularly in situations where GemFire config, and especially, _Gfsh_ were
not used to configure the cluster, which will be true when users upgrade
existing clusters based on an earlier versions of Geode (namely GemFire < v7.0)
and as well as Spring applications.
This change is apparent from the removal of the [conditional check on the Geode
System property
(1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
which is no longer present [here
(2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
or possibly [here
(3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
2. This does not work in the embedded Locator case. If a user configures a
peer Cache using the following in his/her application...
{code:java}
... = new CacheFactory()
.set("name", "Example")
.set("start-locator", "localhost[10334]")
...
.create();
{code}
And another members joins, the logic in (2) above, will fail with...
{code:java}
Caused b
[jira] [Updated] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-1986:
-
Priority: Critical (was: Major)
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Fix For: 1.0.0-incubating
>
>
> A bug was introduced when the logic to fetch the Cluster Configuration
> meta-data from the Locator in the cluster by a member was broken out into it
> is own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing (embedded application) deployments,
> particularly in situations where GemFire config, and especially, _Gfsh_ were
> not used to configure the cluster, which will be true when users upgrade
> existing clusters based on an earlier versions of Geode (namely GemFire <
> v7.0) and as well as Spring applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
John Blum created GEODE-1986:
Summary: The Cluster Configuration Service must absolutely not be
required to run Geode.
Key: GEODE-1986
URL: https://issues.apache.org/jira/browse/GEODE-1986
Project: Geode
Issue Type: Bug
Components: configuration
Reporter: John Blum
Fix For: 1.0.0-incubating
A bug was introduced when the logic to fetch the Cluster Configuration
meta-data from the Locator in the cluster by a member was broken out into it is
own
[class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
causing the following issues...
1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
no longer *optional* (hence, _required_), which is both short sighted and too
restrictive, and will break existing (embedded application) deployments,
particularly in situations where GemFire config, and especially, _Gfsh_ were
not used to configure the cluster, which will be true when users upgrade
existing clusters based on an earlier versions of Geode (namely GemFire < v7.0)
and as well as Spring applications.
This change is apparent from the removal of the [conditional check on the Geode
System property
(1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
which is no longer present [here
(2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
or possibly [here
(3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
2. This does not work in the embedded Locator case. If a user configures a
peer Cache using the following in his/her application...
{code:java}
... = new CacheFactory()
.set("name", "Example")
.set("start-locator", "localhost[10334]")
...
.create();
{code}
And another members joins, the logic in (2) above, will fail with...
{code:java}
Caused by: org.apache.geode.GemFireConfigException: cluster configuration
service not available
at
org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
at
org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
at
org.springframework.data.gemfire.CacheFactoryBean.createCache(CacheFactoryBean.java:354)
at
org.springframework.data.gemfire.CacheFactoryBean.resolveCache(CacheFactoryBean.java:248)
at
org.springframework.data.gemfire.CacheFactoryBean.init(CacheFactoryBean.java:189)
at
org.springframework.data.gemfire.CacheFactoryBean.getObject(CacheFactoryBean.java:175)
at
org.springframework.data.gemfire.CacheFactoryBean.getObject(CacheFactoryBean.java:87)
at
org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:168)
... 36 more
Caused by:
org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
Unable to retrieve cluster configuration from the locator.
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
at
org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
... 47 more
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GEODE-1967) CompactMapRangeIndex loses track when the same entry is deleted and added. Old key are not removed from the removedKeyValuesEntries after it was removed from Compact Ran
[ https://issues.apache.org/jira/browse/GEODE-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun resolved GEODE-1967. Resolution: Fixed > CompactMapRangeIndex loses track when the same entry is deleted and added. > Old key are not removed from the removedKeyValuesEntries after it was removed > from Compact Range Indexes > --- > > Key: GEODE-1967 > URL: https://issues.apache.org/jira/browse/GEODE-1967 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: nabarun > > After the keys are removed from a region and the compact range index was was > updated, the old keys were not removed from removedKeyValuesEntries -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1967) CompactMapRangeIndex loses track when the same entry is deleted and added. Old key are not removed from the removedKeyValuesEntries after it was removed from Compact Ra
[ https://issues.apache.org/jira/browse/GEODE-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564065#comment-15564065 ] ASF subversion and git services commented on GEODE-1967: Commit b2d85b4b0c74c25d7872aaca1bbe520b478563f7 in incubator-geode's branch refs/heads/develop from [~nnag] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=b2d85b4 ] GEODE-1967: Old keys are removed from removedKeyValuesEntries * Old keys are removed from removedKeyValuesEntries after the mapping is removed from Compact map range indexes. * New tests were added to handle various scenarios of old keys being destroyed and then inserted again. > CompactMapRangeIndex loses track when the same entry is deleted and added. > Old key are not removed from the removedKeyValuesEntries after it was removed > from Compact Range Indexes > --- > > Key: GEODE-1967 > URL: https://issues.apache.org/jira/browse/GEODE-1967 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: nabarun > > After the keys are removed from a region and the compact range index was was > updated, the old keys were not removed from removedKeyValuesEntries -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1985) IndexManager.needsRecalculation can miss cases where recalulation is needed
Dan Smith created GEODE-1985: Summary: IndexManager.needsRecalculation can miss cases where recalulation is needed Key: GEODE-1985 URL: https://issues.apache.org/jira/browse/GEODE-1985 Project: Geode Issue Type: Bug Components: querying Reporter: Dan Smith When returning query results from an index, we check IndexManager.needsRecalculation to see if an entry might have changed while the query was in progress. Unfortunately, this method can return false negatives If an entry has not yet updated the SAFE_QUERY_TIME field. The SAFE_QUERY_TIME is updated in LocalRegion.updateStatsForPut. That method is called *after* the region entry was modified. So the SAFE_QUERY_TIME could be 0, even though an entry was modified, which will make this expression false. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1984) Make GatewaySender destroy a public API
Barry Oglesby created GEODE-1984:
Summary: Make GatewaySender destroy a public API
Key: GEODE-1984
URL: https://issues.apache.org/jira/browse/GEODE-1984
Project: Geode
Issue Type: New Feature
Components: wan
Reporter: Barry Oglesby
The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy a
{{GatewaySender}}. This is currently an internal API. It would be nice to make
this public by:
- adding destroy to the {{GatewaySender}} interface
- provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GEODE-1983) Swagger is broken with integrated security
Diane Hardman created GEODE-1983: Summary: Swagger is broken with integrated security Key: GEODE-1983 URL: https://issues.apache.org/jira/browse/GEODE-1983 Project: Geode Issue Type: Bug Components: rest (dev), security Reporter: Diane Hardman Swagger UI does not work with latest integrated security. After configuring security manager and attempting up to open up Swagger UI we get a prompt for username and password. Entering credentials does not bring up the UI, instead asking for credentials again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1548) jmx-manager-hostname-for-clients not honored
[
https://issues.apache.org/jira/browse/GEODE-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-1548.
Resolution: Fixed (was: Not A Bug)
Fix Version/s: 1.0.0-incubating
> jmx-manager-hostname-for-clients not honored
>
>
> Key: GEODE-1548
> URL: https://issues.apache.org/jira/browse/GEODE-1548
> Project: Geode
> Issue Type: Bug
> Components: gfsh, management
>Reporter: Swapnil Bawaskar
>Assignee: Jared Stewart
> Fix For: 1.0.0-incubating
>
>
> While running Geode on AWS, found that {{jmx-manager-hostname-for-clients}}
> is not being honored resulting in not being able to connect to gfsh from
> outside AWS.
> I started a locator in AWS with the following command:
> {noformat}
> gfsh>start locator --name=locator
> --J=-Dgemfire.jmx-manager-hostname-for-clients=
> --hostname-for-clients=
> {noformat}
> When trying to connect to this locator from my laptop I get the following
> error:
> {noformat}
> gfsh>connect --locator=52.41.104.182[10334]
> Connecting to Locator at [host=52.41.104.182, port=10334] ..
> Connecting to Manager at
> [host=ec2-52-41-104-182.us-west-2.compute.amazonaws.com, port=1099] ..
> Could not connect to :
> [host=ec2-52-41-104-182.us-west-2.compute.amazonaws.com, port=1099]. Failed
> to retrieve RMIServer stub: javax.naming.CommunicationException [Root
> exception is java.rmi.ConnectIOException: error during JRMP connection
> establishment; nested exception is:
> java.net.SocketException: Connection reset]
> {noformat}
> Note that gfsh is trying to connect to the public dns for the instance, not
> using the {{jmx-manager-hostname-for-clients}} property provided.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1959) Prompt for username and password when adding a member
[ https://issues.apache.org/jira/browse/GEODE-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling updated GEODE-1959: Attachment: security.json gemfire.properties Configuration files needed to reproduce problem > Prompt for username and password when adding a member > - > > Key: GEODE-1959 > URL: https://issues.apache.org/jira/browse/GEODE-1959 > Project: Geode > Issue Type: Improvement > Components: security >Reporter: Diane Hardman >Assignee: Kevin Duling > Attachments: gemfire.properties, security.json > > > When you have SecurityManager configured as part of starting a locator, the > administrator currently needs to have either AuthInitialize implemented or > have stored credentials (in plain text) in geode.properties file. In the case > where neither AuthInitialize is implemented NOR are there any credentials > stored in geode.properties, then the administrator should be prompted for > username and password when attempting to start another member in the > distributed system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (GEODE-337) CI failure: ClientHealthStatsDUnitTest.testStatsMatchWithSize
[ https://issues.apache.org/jira/browse/GEODE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker reopened GEODE-337: - > CI failure: ClientHealthStatsDUnitTest.testStatsMatchWithSize > - > > Key: GEODE-337 > URL: https://issues.apache.org/jira/browse/GEODE-337 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Jason Huynh >Assignee: Bruce Schuchardt > Labels: CI > Fix For: 1.0.0-incubating.M1 > > > While running tests the following issue occurred for this test: > dunit.RMIException: While invoking > com.gemstone.gemfire.management.ClientHealthStatsDUnitTest.createClientCache > in VM 2 running on Host zambia.gemstone.com with 4 VMs > at dunit.VM.invoke(VM.java:161) > at > com.gemstone.gemfire.management.ClientHealthStatsDUnitTest.testStatsMatchWithSize(ClientHealthStatsDUnitTest.java:195) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at junit.framework.TestCase.runTest(TestCase.java:176) > at junit.framework.TestCase.runBare(TestCase.java:141) > at junit.framework.TestResult$1.protect(TestResult.java:122) > at junit.framework.TestResult.runProtected(TestResult.java:142) > at junit.framework.TestResult.run(TestResult.java:125) > at junit.framework.TestCase.run(TestCase.java:129) > at junit.framework.TestSuite.runTest(TestSuite.java:252) > at junit.framework.TestSuite.run(TestSuite.java:247) > at > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:86) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:49) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.messaging.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:106) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360) > at > org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64) > 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: > com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: > com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: Could not > initialize a primary queue on startup. No queue servers available. > at > com.gemstone.gemfire.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:190) > at > com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:522) > at > com.gemstone.gemfire.cache.client.internal.Po
[jira] [Assigned] (GEODE-1959) Prompt for username and password when adding a member
[ https://issues.apache.org/jira/browse/GEODE-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling reassigned GEODE-1959: --- Assignee: Kevin Duling > Prompt for username and password when adding a member > - > > Key: GEODE-1959 > URL: https://issues.apache.org/jira/browse/GEODE-1959 > Project: Geode > Issue Type: Improvement > Components: security >Reporter: Diane Hardman >Assignee: Kevin Duling > > When you have SecurityManager configured as part of starting a locator, the > administrator currently needs to have either AuthInitialize implemented or > have stored credentials (in plain text) in geode.properties file. In the case > where neither AuthInitialize is implemented NOR are there any credentials > stored in geode.properties, then the administrator should be prompted for > username and password when attempting to start another member in the > distributed system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1972) Move Geode Hibernate module to a feature branch
[ https://issues.apache.org/jira/browse/GEODE-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563691#comment-15563691 ] ASF subversion and git services commented on GEODE-1972: Commit 46b95d4c55d7617b98c1f02341592c756ee4e4e9 in incubator-geode's branch refs/heads/develop from [~huynhja] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=46b95d4 ] GEODE-1972: Move Geode Hibernate module to a feature branch > Move Geode Hibernate module to a feature branch > --- > > Key: GEODE-1972 > URL: https://issues.apache.org/jira/browse/GEODE-1972 > Project: Geode > Issue Type: Task > Components: hibernate >Reporter: Jason Huynh > > There was discussion on the mailing list to remove hibernate or at least move > the hibernate module into a feature branch until it can be updated and > remerged back into geode. > This is a ticket for that work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1570) developer REST API should be secured
[ https://issues.apache.org/jira/browse/GEODE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563689#comment-15563689 ] ASF subversion and git services commented on GEODE-1570: Commit 2b0b55ea93f372da1b06848644e27de725c11da9 in incubator-geode's branch refs/heads/develop from [~jinmeiliao] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=2b0b55e ] GEODE-1570: make GemFireVersion.properties available in the geode-core test source so that other projects that depends on the geode-core-test can access it. > developer REST API should be secured > > > Key: GEODE-1570 > URL: https://issues.apache.org/jira/browse/GEODE-1570 > Project: Geode > Issue Type: Sub-task > Components: rest (dev), security >Reporter: Swapnil Bawaskar >Assignee: Kevin Duling > Fix For: 1.0.0-incubating > > > The developer REST API should require authentication when security is > enabled. For authorization, the implementation should use the new > Resource:Operation permissions API that is used by JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1570) developer REST API should be secured
[ https://issues.apache.org/jira/browse/GEODE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563688#comment-15563688 ] ASF subversion and git services commented on GEODE-1570: Commit 5ed443d5bf8be3943fa76ce457f9592df5eb8317 in incubator-geode's branch refs/heads/develop from [~kduling] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=5ed443d ] GEODE-1570 - developer REST API should be secured * Merged with develop after org.apache package rename * Moved classes to internal. * this closes #251 > developer REST API should be secured > > > Key: GEODE-1570 > URL: https://issues.apache.org/jira/browse/GEODE-1570 > Project: Geode > Issue Type: Sub-task > Components: rest (dev), security >Reporter: Swapnil Bawaskar >Assignee: Kevin Duling > Fix For: 1.0.0-incubating > > > The developer REST API should require authentication when security is > enabled. For authorization, the implementation should use the new > Resource:Operation permissions API that is used by JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1570) developer REST API should be secured
[ https://issues.apache.org/jira/browse/GEODE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563690#comment-15563690 ] ASF subversion and git services commented on GEODE-1570: Commit a7b9ac13d542a5e63a633e54d9b1b527703e3511 in incubator-geode's branch refs/heads/develop from [~jinmeiliao] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=a7b9ac1 ] GEODE-1570: upgrade spring libraries * upgrade the spring libraries and related libraries * upgrade version numbers in the NOTICE and LICENSE file * some test refactor > developer REST API should be secured > > > Key: GEODE-1570 > URL: https://issues.apache.org/jira/browse/GEODE-1570 > Project: Geode > Issue Type: Sub-task > Components: rest (dev), security >Reporter: Swapnil Bawaskar >Assignee: Kevin Duling > Fix For: 1.0.0-incubating > > > The developer REST API should require authentication when security is > enabled. For authorization, the implementation should use the new > Resource:Operation permissions API that is used by JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1242) HARegionQueue.addDispatchedMessage fails with assertion
[
https://issues.apache.org/jira/browse/GEODE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xiaojian zhou resolved GEODE-1242.
--
Resolution: Fixed
It has been fixed in GEODE-1183, revision
51e4e71ef1ffb2fddb3ade42e0ad46fe40886239
> HARegionQueue.addDispatchedMessage fails with assertion
> ---
>
> Key: GEODE-1242
> URL: https://issues.apache.org/jira/browse/GEODE-1242
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Darrel Schneider
>Assignee: xiaojian zhou
>
> CacheClientNotifierDUnitTest.testMultipleCacheServer failed with this suspect
> string which is caused by a failed assertion in the product code:
> Object old = ((ConcurrentMap)tempDispatchedMessagesMap).putIfAbsent(
> this.regionName, this.threadIdToSeqId);
> if (isUsedByTest) {
> testMarkerMessageRecieved = true;
> if (logger.isDebugEnabled()) {
> logger.debug("testIsAckRecieved: {}", testMarkerMessageRecieved);
> }
> }
> Assert.assertTrue(old == null);
> Here is the suspect string stack:Found suspect string in log4j at line 2564
> [fatal 2016/04/16 02:52:53.399 UTC
> tid=0x71] Server connection from
> [identity(ip-10-32-36-249(14674:loner):50509:c338fc1c,connection=1;
> port=50568] : Unexpected Error on server
> com.gemstone.gemfire.InternalGemFireError
> at com.gemstone.gemfire.internal.Assert.throwError(Assert.java:93)
> at com.gemstone.gemfire.internal.Assert.assertTrue(Assert.java:57)
> at
> com.gemstone.gemfire.internal.cache.ha.HARegionQueue.addDispatchedMessage(HARegionQueue.java:1758)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.CacheClientNotifier.processDispatchedMessage(CacheClientNotifier.java:733)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.command.PeriodicAck.cmdExecute(PeriodicAck.java:56)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:175)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:805)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:932)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1181)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:560)
> at java.lang.Thread.run(Thread.java:745)
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:354)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:543)
> at ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-1242) HARegionQueue.addDispatchedMessage fails with assertion
[
https://issues.apache.org/jira/browse/GEODE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xiaojian zhou reassigned GEODE-1242:
Assignee: xiaojian zhou
> HARegionQueue.addDispatchedMessage fails with assertion
> ---
>
> Key: GEODE-1242
> URL: https://issues.apache.org/jira/browse/GEODE-1242
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Darrel Schneider
>Assignee: xiaojian zhou
>
> CacheClientNotifierDUnitTest.testMultipleCacheServer failed with this suspect
> string which is caused by a failed assertion in the product code:
> Object old = ((ConcurrentMap)tempDispatchedMessagesMap).putIfAbsent(
> this.regionName, this.threadIdToSeqId);
> if (isUsedByTest) {
> testMarkerMessageRecieved = true;
> if (logger.isDebugEnabled()) {
> logger.debug("testIsAckRecieved: {}", testMarkerMessageRecieved);
> }
> }
> Assert.assertTrue(old == null);
> Here is the suspect string stack:Found suspect string in log4j at line 2564
> [fatal 2016/04/16 02:52:53.399 UTC
> tid=0x71] Server connection from
> [identity(ip-10-32-36-249(14674:loner):50509:c338fc1c,connection=1;
> port=50568] : Unexpected Error on server
> com.gemstone.gemfire.InternalGemFireError
> at com.gemstone.gemfire.internal.Assert.throwError(Assert.java:93)
> at com.gemstone.gemfire.internal.Assert.assertTrue(Assert.java:57)
> at
> com.gemstone.gemfire.internal.cache.ha.HARegionQueue.addDispatchedMessage(HARegionQueue.java:1758)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.CacheClientNotifier.processDispatchedMessage(CacheClientNotifier.java:733)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.command.PeriodicAck.cmdExecute(PeriodicAck.java:56)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:175)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:805)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:932)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1181)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:560)
> at java.lang.Thread.run(Thread.java:745)
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:354)
> at
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:543)
> at ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1926) The function peekAhead function puts the queue key into peekedIDs even though it was not in the batch to be dispatched
[ https://issues.apache.org/jira/browse/GEODE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563515#comment-15563515 ] ASF subversion and git services commented on GEODE-1926: Commit a0acc3ca646a72379f8fc25297d5301ffd95da80 in incubator-geode's branch refs/heads/develop from [~nnag] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=a0acc3c ] GEODE-1926: Removing the extra getObjectInSerialSenderQueue call * This was causing few tests to hang waiting for queues to drain. > The function peekAhead function puts the queue key into peekedIDs even though > it was not in the batch to be dispatched > --- > > Key: GEODE-1926 > URL: https://issues.apache.org/jira/browse/GEODE-1926 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: nabarun > > The function peekAhead peeks the serial sender queue and if its able to get > an object in the queue, returns the object to the peek function to be > dispatched and adds the key to the peekedIds list. > The peek function tries to make a heap copy of the object returned , but > conflation may have kicked in the object may have been removed - hence the > object will not be placed in the dispatch batch. > However now the size of the peeked Ids and dispatched batch do not match, > hence when the remove thread starts removing the elements from the key using > the keys in peekedIds and using the size of the dispatched batch, there will > be lingering objects in the queue because the size of dispatched batch is > less than Ids that were peeked. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1956) CI failure: LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate
[ https://issues.apache.org/jira/browse/GEODE-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563439#comment-15563439 ] ASF subversion and git services commented on GEODE-1956: Commit 4b3ae78675bedc7c1bc3ee247fbd66f465614b79 in incubator-geode's branch refs/heads/develop from zhouxh [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=4b3ae78 ] GEODE-1956: fix the race condition that cause the vm only hosts 1 primary bucket > CI failure: > LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate > - > > Key: GEODE-1956 > URL: https://issues.apache.org/jira/browse/GEODE-1956 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Bruce Schuchardt >Assignee: xiaojian zhou > Labels: CI > > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest$$Lambda$50/1718051859.run > in VM 0 running on Host cc2-rh6.gemstone.com with 4 VMs > at org.apache.geode.test.dunit.VM.invoke(VM.java:389) > at org.apache.geode.test.dunit.VM.invoke(VM.java:355) > at org.apache.geode.test.dunit.VM.invoke(VM.java:293) > at > org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate(LuceneQueriesPeerPRRedundancyDUnitTest.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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(Nati
[jira] [Commented] (GEODE-1956) CI failure: LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate
[ https://issues.apache.org/jira/browse/GEODE-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563097#comment-15563097 ] ASF subversion and git services commented on GEODE-1956: Commit 639c856021ec9321cdc0895a5e1503a6296dc765 in incubator-geode's branch refs/heads/master from [~amb] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=639c856 ] Revert "GEODE-1956: fix the race condition that cause the vm only hosts 1 primary bucket" This reverts commit c3162e0b9d7315c4665ebd05e26515228f9e89de. > CI failure: > LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate > - > > Key: GEODE-1956 > URL: https://issues.apache.org/jira/browse/GEODE-1956 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Bruce Schuchardt >Assignee: xiaojian zhou > Labels: CI > > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest$$Lambda$50/1718051859.run > in VM 0 running on Host cc2-rh6.gemstone.com with 4 VMs > at org.apache.geode.test.dunit.VM.invoke(VM.java:389) > at org.apache.geode.test.dunit.VM.invoke(VM.java:355) > at org.apache.geode.test.dunit.VM.invoke(VM.java:293) > at > org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate(LuceneQueriesPeerPRRedundancyDUnitTest.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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(TestWorke
[jira] [Commented] (GEODE-1980) CI Failure: DiskStoreCommandsDUnitTest.testCreateDestroyUpdatesSharedConfig
[ https://issues.apache.org/jira/browse/GEODE-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563074#comment-15563074 ] Anthony Baker commented on GEODE-1980: -- May also be related to GEODE-1406. > CI Failure: DiskStoreCommandsDUnitTest.testCreateDestroyUpdatesSharedConfig > --- > > Key: GEODE-1980 > URL: https://issues.apache.org/jira/browse/GEODE-1980 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Barry Oglesby > > This looks similar to GEODE-1954, but slightly different line numbers. > Geode_develop_DistributedTests > Private Build #4129 > Revision: 0a6e1a5339243b069a04d8010a869bfd1f4172c1 > Error Message > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.management.internal.cli.commands.DiskStoreCommandsDUnitTest$25.call > in VM 1 running on Host cc4-rh6.gemstone.com with 4 VMs > Stacktrace > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.management.internal.cli.commands.DiskStoreCommandsDUnitTest$25.call > in VM 1 running on Host cc4-rh6.gemstone.com with 4 VMs > at org.apache.geode.test.dunit.VM.invoke(VM.java:389) > at org.apache.geode.test.dunit.VM.invoke(VM.java:355) > at org.apache.geode.test.dunit.VM.invoke(VM.java:320) > at > org.apache.geode.management.internal.cli.commands.DiskStoreCommandsDUnitTest.testCreateDestroyUpdatesSharedConfig(DiskStoreCommandsDUnitTest.java:768) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > 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.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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 >
[jira] [Resolved] (GEODE-1956) CI failure: LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate
[ https://issues.apache.org/jira/browse/GEODE-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xiaojian zhou resolved GEODE-1956. -- Resolution: Fixed > CI failure: > LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate > - > > Key: GEODE-1956 > URL: https://issues.apache.org/jira/browse/GEODE-1956 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Bruce Schuchardt >Assignee: xiaojian zhou > Labels: CI > > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest$$Lambda$50/1718051859.run > in VM 0 running on Host cc2-rh6.gemstone.com with 4 VMs > at org.apache.geode.test.dunit.VM.invoke(VM.java:389) > at org.apache.geode.test.dunit.VM.invoke(VM.java:355) > at org.apache.geode.test.dunit.VM.invoke(VM.java:293) > at > org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate(LuceneQueriesPeerPRRedundancyDUnitTest.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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:497) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(Ref
[jira] [Commented] (GEODE-1956) CI failure: LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate
[ https://issues.apache.org/jira/browse/GEODE-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563053#comment-15563053 ] ASF subversion and git services commented on GEODE-1956: Commit c3162e0b9d7315c4665ebd05e26515228f9e89de in incubator-geode's branch refs/heads/master from zhouxh [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=c3162e0 ] GEODE-1956: fix the race condition that cause the vm only hosts 1 primary bucket > CI failure: > LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate > - > > Key: GEODE-1956 > URL: https://issues.apache.org/jira/browse/GEODE-1956 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Bruce Schuchardt >Assignee: xiaojian zhou > Labels: CI > > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest$$Lambda$50/1718051859.run > in VM 0 running on Host cc2-rh6.gemstone.com with 4 VMs > at org.apache.geode.test.dunit.VM.invoke(VM.java:389) > at org.apache.geode.test.dunit.VM.invoke(VM.java:355) > at org.apache.geode.test.dunit.VM.invoke(VM.java:293) > at > org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate(LuceneQueriesPeerPRRedundancyDUnitTest.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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(Nativ
[jira] [Commented] (GEODE-1972) Move Geode Hibernate module to a feature branch
[ https://issues.apache.org/jira/browse/GEODE-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563022#comment-15563022 ] Jason Huynh commented on GEODE-1972: Currently removed from the release branch, if anyone wants to work on the hibernate module, they can create a feature branch and revert the 38aa36f4eb4df61333e17dab4abf9952baf2000b commit. > Move Geode Hibernate module to a feature branch > --- > > Key: GEODE-1972 > URL: https://issues.apache.org/jira/browse/GEODE-1972 > Project: Geode > Issue Type: Task > Components: hibernate >Reporter: Jason Huynh > > There was discussion on the mailing list to remove hibernate or at least move > the hibernate module into a feature branch until it can be updated and > remerged back into geode. > This is a ticket for that work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1972) Move Geode Hibernate module to a feature branch
[ https://issues.apache.org/jira/browse/GEODE-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563016#comment-15563016 ] ASF subversion and git services commented on GEODE-1972: Commit 38aa36f4eb4df61333e17dab4abf9952baf2000b in incubator-geode's branch refs/heads/release/1.0.0-incubating from [~huynhja] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=38aa36f ] GEODE-1972: Move Geode Hibernate module to a feature branch > Move Geode Hibernate module to a feature branch > --- > > Key: GEODE-1972 > URL: https://issues.apache.org/jira/browse/GEODE-1972 > Project: Geode > Issue Type: Task > Components: hibernate >Reporter: Jason Huynh > > There was discussion on the mailing list to remove hibernate or at least move > the hibernate module into a feature branch until it can be updated and > remerged back into geode. > This is a ticket for that work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1973) GMSAuthenticator needs to work in a locator without cache
[ https://issues.apache.org/jira/browse/GEODE-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15562884#comment-15562884 ] ASF subversion and git services commented on GEODE-1973: Commit 68aef5b7fbdb7ff740d5fbbc66c7848f14b834ff in incubator-geode's branch refs/heads/develop from [~jinmeiliao] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=68aef5b ] GEODE-1973: add more tests to cover GMSAuthenticator and SimpleSecurityManager * adding more tests > GMSAuthenticator needs to work in a locator without cache > - > > Key: GEODE-1973 > URL: https://issues.apache.org/jira/browse/GEODE-1973 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Jinmei Liao >Assignee: Jinmei Liao > > GMSAuthenticator needs to work in a locator without cache -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1914) Geode source code contains old version of gemfire dtds
[ https://issues.apache.org/jira/browse/GEODE-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hitesh Khamesra resolved GEODE-1914. Resolution: Fixed > Geode source code contains old version of gemfire dtds > -- > > Key: GEODE-1914 > URL: https://issues.apache.org/jira/browse/GEODE-1914 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Hitesh Khamesra >Assignee: Hitesh Khamesra > Fix For: 1.0.0-incubating > > > Geode source contains old version of gemfire dtds that can be drop. That are > referred by tests as well . And we may need to remove or upgrade those tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1570) developer REST API should be secured
[ https://issues.apache.org/jira/browse/GEODE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling resolved GEODE-1570. - Resolution: Fixed > developer REST API should be secured > > > Key: GEODE-1570 > URL: https://issues.apache.org/jira/browse/GEODE-1570 > Project: Geode > Issue Type: Sub-task > Components: rest (dev), security >Reporter: Swapnil Bawaskar >Assignee: Kevin Duling > Fix For: 1.0.0-incubating > > > The developer REST API should require authentication when security is > enabled. For authorization, the implementation should use the new > Resource:Operation permissions API that is used by JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1914) Geode source code contains old version of gemfire dtds
[ https://issues.apache.org/jira/browse/GEODE-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15562730#comment-15562730 ] ASF subversion and git services commented on GEODE-1914: Commit 33cdf68867b0d7fb7d869e95ffc05ac96419098a in incubator-geode's branch refs/heads/develop from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=33cdf68 ] GEODE-1914 Removed old dtds from geode source code(kept 7.0 and above) Deteted old tests and updated test xmls to point 7.0 dtd > Geode source code contains old version of gemfire dtds > -- > > Key: GEODE-1914 > URL: https://issues.apache.org/jira/browse/GEODE-1914 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Hitesh Khamesra >Assignee: Hitesh Khamesra > Fix For: 1.0.0-incubating > > > Geode source contains old version of gemfire dtds that can be drop. That are > referred by tests as well . And we may need to remove or upgrade those tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
