[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=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=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=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=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",
[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=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=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
[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=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=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.invoke0(Native
[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=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=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=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=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=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
[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] [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] [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 >
[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-1570) developer REST API should be secured
[ https://issues.apache.org/jira/browse/GEODE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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] [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] [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=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=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(TestWorker.java:109) >
[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=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 >
[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=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(Native Method) >
[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=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=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=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)
