[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632873#comment-15632873
]
Jinmei Liao edited comment on GEODE-1986 at 11/3/16 2:32 PM:
-
The fix was put in on 10/11, I believe by that time, 1.0.0 is already out. I've
updated the fixed version of this ticket. The fix is also in 9.0 support branch.
Do we need to backport this to 1.0.0? A simple workaround of this problem is to
set enable-cluster-configuration=false when you start up the embedded locator
(your server 1).
was (Author: jinmeiliao):
The fix was put in on 10/11, I believe by that time, 1.0.0 is already out. I've
updated the fixed version of this ticket. The fix is also in 9.0 support branch.
> 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
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.1.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631201#comment-15631201
]
John Blum edited comment on GEODE-1986 at 11/3/16 2:06 AM:
---
1 final comment; I am not sure that this is a problem for
{{1.1.0-incubating-SNAPSHOT}}, which basically means that the fix for this bug
([GEODE-1986]) did **NOT** make it into Apache Geode {{1.0.0-incubating}} GA
release as
[advertised|https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating+Release]!
Additionally, this problem did not exist in the {{1.0.0-incubating.M3}} release
either.
Anyway, I am able to successfully run 1 of the failing tests in SDG
[GemfireTemplateQueriesOnGroupedPooledClientCacheRegionsIntegrationTests|https://github.com/spring-projects/spring-data-gemfire/blob/1.0.0.APACHE-GEODE-INCUBATING-M3/src/test/java/org/springframework/data/gemfire/GemfireTemplateQueriesOnGroupedPooledClientCacheRegionsIntegrationTests.java]
with {{1.1.0-incubating-SNAPSHOT}}.
I suspect that the _Gfsh_ test procedure would work for
{{1.1.0-incubating-SNAPSHOT}} as well.
was (Author: jblum):
1 final comment; I am not sure that this is a problem for
{{1.1.0-incubating-SNAPSHOT}}, which basically means that the fix for this bug
([GEODE-1986]) did **NOT** make it into Apache Geode {{1.0.0-incubating}} GA
release as
[advertised|https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating+Release]!
Additionally, this problem did not exist in the {{1.0.0-incubating.M3}} release
either.
Anyway, I am able to successfully run 1 of the failing tests in SDG
[GemfireTemplateQueriesOnGroupedPooledClientCacheRegionsIntegrationTests|https://github.com/spring-projects/spring-data-gemfire/blob/1.0.0.APACHE-GEODE-INCUBATING-M3/src/test/java/org/springframework/data/gemfire/GemfireTemplateQueriesOnGroupedPooledClientCacheRegionsIntegrationTests.java]
with {{1.1.0-incubating-SNAPSHOT}}.
I suspect that the _Gfsh_ procedure would work for
{{1.1.0-incubating-SNAPSHOT}} as well.
> 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
>Assignee: Jinmei Liao
>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(GemFireCache
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631201#comment-15631201
]
John Blum edited comment on GEODE-1986 at 11/3/16 2:01 AM:
---
1 final comment; I am not sure that this is a problem for
{{1.1.0-incubating-SNAPSHOT}}, which basically means that the fix for this bug
([GEODE-1986]) did **NOT** make it into Apache Geode {{1.0.0-incubating}} GA
release as
[advertised|https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating+Release]!
Additionally, this problem did not exist in the {{1.0.0-incubating.M3}} release
either.
Anyway, I am able to successfully run 1 of the failing tests in SDG
[GemfireTemplateQueriesOnGroupedPooledClientCacheRegionsIntegrationTests|https://github.com/spring-projects/spring-data-gemfire/blob/1.0.0.APACHE-GEODE-INCUBATING-M3/src/test/java/org/springframework/data/gemfire/GemfireTemplateQueriesOnGroupedPooledClientCacheRegionsIntegrationTests.java]
with {{1.1.0-incubating-SNAPSHOT}}.
I suspect that the _Gfsh_ procedure would work for
{{1.1.0-incubating-SNAPSHOT}} as well.
was (Author: jblum):
1 final comment; I am not sure that this is a problem for
{{1.1.0-incubating-SNAPSHOT}}, which basically means that the fix for this bug
([GEODE-1986]) did **NOT** make it into Apache Geode {{1.0.0-incubating}} GA
release as
[advertised|https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating+Release]!
Additionally, this problem did not exist in the {{1.0.0-incubating.M3}} release
either.
> 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
>Assignee: Jinmei Liao
>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
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631201#comment-15631201
]
John Blum edited comment on GEODE-1986 at 11/3/16 1:55 AM:
---
1 final comment; I am not sure that this is a problem for
{{1.1.0-incubating-SNAPSHOT}}, which basically means that the fix for this bug
([GEODE-1986]) did **NOT** make it into Apache Geode {{1.0.0-incubating}} GA
release as
[advertised|https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating+Release]!
Additionally, this problem did not exist in the {{1.0.0-incubating.M3}} release
either.
was (Author: jblum):
1 final comment; I am not sure that this is a problem for
{{1.1.0-incubating-SNAPSHOT}}, which basically means that the fix for this bug
([GEODE-1986]) did **NOT** make it into Apache Geode {{1.0.0-incubating}} GA
release as
[advertised|https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating+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
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.0.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631176#comment-15631176
]
John Blum edited comment on GEODE-1986 at 11/3/16 1:43 AM:
---
A couple of "gems" concerning my {{start server}} command-lines in my _Gfsh_
session above (previous comment)...
1. {{--disable-default-server}} does not prevent the "Geode Server" from trying
to start on the default {{CacheServer}} port (*40404*) anyway
When I attempt to start my second server ("Server2") the firs time if failed
with...
{code}
gfsh>start server --name=Server2 --log-level=config
--J=-Dgemfire.locators=localhost[10334] --disable-default-server
Starting a Geode Server in /Users/jblum/pivdev/lab/Server2...
The Cache Server process terminated unexpectedly with exit status 1. Please
refer to the log file in /Users/jblum/pivdev/lab/Server2 for full details.
Exception in thread "main" java.lang.RuntimeException: An IO error occurred
while starting a Server in /Users/jblum/pivdev/lab/Server2 on
10.99.199.3[40404]: Network is unreachable; port (40404) is not available on
localhost.
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:735)
at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633)
at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:184)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost.
at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:127)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:688)
... 2 more
{code}
2. Second, the {{\-\-locators}} option on {{start server}} is broken, hence the
reason I specified {{\--server-port}} for both servers on start to avoid bind
Exceptions and used the {{--J}} option to specify the embedded Locator of
"Server1" with the {{gemfire.locators}} System property when starting
"Server2".
Otherwise, "Server2" starts in standalone mode!
was (Author: jblum):
A couple of "gems" concerning my {{start server}} command-lines in my _Gfsh_
session above (previous comment)...
1. {{--disable-default-server}} does not prevent the "Geode Server" from trying
to start on the default {{CacheServer}} port (*40404*) anyway
When I attempt to start my second server ("Server2") the firs time if failed
with...
{code}
gfsh>start server --name=Server2 --log-level=config
--J=-Dgemfire.locators=localhost[10334] --disable-default-server
Starting a Geode Server in /Users/jblum/pivdev/lab/Server2...
The Cache Server process terminated unexpectedly with exit status 1. Please
refer to the log file in /Users/jblum/pivdev/lab/Server2 for full details.
Exception in thread "main" java.lang.RuntimeException: An IO error occurred
while starting a Server in /Users/jblum/pivdev/lab/Server2 on
10.99.199.3[40404]: Network is unreachable; port (40404) is not available on
localhost.
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:735)
at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633)
at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:184)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost.
at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:127)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:688)
... 2 more
{code}
2. Second, the {{\--locators}} option on {{start server}} is broken, hence the
reason I specified {{\--server-port}} for both servers on start to avoid bind
Exceptions and used the {{--J}} option to specify the embedded Locator of
"Server1" with the {{gemfire.locators}} System property when starting
"Server2".
Otherwise, "Server2" starts in standalone mode!
> 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
>Assignee: Jinmei Liao
>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
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631176#comment-15631176
]
John Blum edited comment on GEODE-1986 at 11/3/16 1:43 AM:
---
A couple of "gems" concerning my {{start server}} command-lines in my _Gfsh_
session above (previous comment)...
1. {{--disable-default-server}} does not prevent the "Geode Server" from trying
to start on the default {{CacheServer}} port (*40404*) anyway
When I attempt to start my second server ("Server2") the firs time if failed
with...
{code}
gfsh>start server --name=Server2 --log-level=config
--J=-Dgemfire.locators=localhost[10334] --disable-default-server
Starting a Geode Server in /Users/jblum/pivdev/lab/Server2...
The Cache Server process terminated unexpectedly with exit status 1. Please
refer to the log file in /Users/jblum/pivdev/lab/Server2 for full details.
Exception in thread "main" java.lang.RuntimeException: An IO error occurred
while starting a Server in /Users/jblum/pivdev/lab/Server2 on
10.99.199.3[40404]: Network is unreachable; port (40404) is not available on
localhost.
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:735)
at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633)
at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:184)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost.
at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:127)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:688)
... 2 more
{code}
2. Second, the {{\-\-locators}} option on {{start server}} is broken, hence the
reason I specified {{\-\-server-port}} for both servers on start to avoid bind
Exceptions and used the {{--J}} option to specify the embedded Locator of
"Server1" with the {{gemfire.locators}} System property when starting
"Server2".
Otherwise, "Server2" starts in standalone mode!
was (Author: jblum):
A couple of "gems" concerning my {{start server}} command-lines in my _Gfsh_
session above (previous comment)...
1. {{--disable-default-server}} does not prevent the "Geode Server" from trying
to start on the default {{CacheServer}} port (*40404*) anyway
When I attempt to start my second server ("Server2") the firs time if failed
with...
{code}
gfsh>start server --name=Server2 --log-level=config
--J=-Dgemfire.locators=localhost[10334] --disable-default-server
Starting a Geode Server in /Users/jblum/pivdev/lab/Server2...
The Cache Server process terminated unexpectedly with exit status 1. Please
refer to the log file in /Users/jblum/pivdev/lab/Server2 for full details.
Exception in thread "main" java.lang.RuntimeException: An IO error occurred
while starting a Server in /Users/jblum/pivdev/lab/Server2 on
10.99.199.3[40404]: Network is unreachable; port (40404) is not available on
localhost.
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:735)
at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633)
at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:184)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost.
at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:127)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:688)
... 2 more
{code}
2. Second, the {{\-\-locators}} option on {{start server}} is broken, hence the
reason I specified {{\--server-port}} for both servers on start to avoid bind
Exceptions and used the {{--J}} option to specify the embedded Locator of
"Server1" with the {{gemfire.locators}} System property when starting
"Server2".
Otherwise, "Server2" starts in standalone mode!
> 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
>Assignee: Jinmei Liao
>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 foremo
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631176#comment-15631176
]
John Blum edited comment on GEODE-1986 at 11/3/16 1:43 AM:
---
A couple of "gems" concerning my {{start server}} command-lines in my _Gfsh_
session above (previous comment)...
1. {{--disable-default-server}} does not prevent the "Geode Server" from trying
to start on the default {{CacheServer}} port (*40404*) anyway
When I attempt to start my second server ("Server2") the firs time if failed
with...
{code}
gfsh>start server --name=Server2 --log-level=config
--J=-Dgemfire.locators=localhost[10334] --disable-default-server
Starting a Geode Server in /Users/jblum/pivdev/lab/Server2...
The Cache Server process terminated unexpectedly with exit status 1. Please
refer to the log file in /Users/jblum/pivdev/lab/Server2 for full details.
Exception in thread "main" java.lang.RuntimeException: An IO error occurred
while starting a Server in /Users/jblum/pivdev/lab/Server2 on
10.99.199.3[40404]: Network is unreachable; port (40404) is not available on
localhost.
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:735)
at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633)
at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:184)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost.
at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:127)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:688)
... 2 more
{code}
2. Second, the {{\--locators}} option on {{start server}} is broken, hence the
reason I specified {{\--server-port}} for both servers on start to avoid bind
Exceptions and used the {{--J}} option to specify the embedded Locator of
"Server1" with the {{gemfire.locators}} System property when starting
"Server2".
Otherwise, "Server2" starts in standalone mode!
was (Author: jblum):
A couple of "gems" concerning my {{start server}} command-lines in my _Gfsh_
session above (previous comment)...
1. {{--disable-default-server}} does not prevent the "Geode Server" from trying
to start on the default {{CacheServer}} port (*40404*) anyway
When I attempt to start my second server ("Server2") the firs time if failed
with...
{code}
gfsh>start server --name=Server2 --log-level=config
--J=-Dgemfire.locators=localhost[10334] --disable-default-server
Starting a Geode Server in /Users/jblum/pivdev/lab/Server2...
The Cache Server process terminated unexpectedly with exit status 1. Please
refer to the log file in /Users/jblum/pivdev/lab/Server2 for full details.
Exception in thread "main" java.lang.RuntimeException: An IO error occurred
while starting a Server in /Users/jblum/pivdev/lab/Server2 on
10.99.199.3[40404]: Network is unreachable; port (40404) is not available on
localhost.
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:735)
at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633)
at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:184)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost.
at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:127)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:688)
... 2 more
{code}
2. Second, the {{--locators}} option on {{start server}} is broken, hence the
reason I specified {{--server-port}} for both servers on start to avoid bind
Exceptions and used the {{--J}} option to specify the embedded Locator of
"Server1" with the {{gemfire.locators}} System property when starting
"Server2".
Otherwise, "Server2" starts in standalone mode!
> 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
>Assignee: Jinmei Liao
>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, t
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631176#comment-15631176
]
John Blum edited comment on GEODE-1986 at 11/3/16 1:42 AM:
---
A couple of "gems" concerning my {{start server}} command-lines in my _Gfsh_
session above (previous comment)...
1. {{--disable-default-server}} does not prevent the "Geode Server" from trying
to start on the default {{CacheServer}} port (*40404*) anyway
When I attempt to start my second server ("Server2") the firs time if failed
with...
{code}
gfsh>start server --name=Server2 --log-level=config
--J=-Dgemfire.locators=localhost[10334] --disable-default-server
Starting a Geode Server in /Users/jblum/pivdev/lab/Server2...
The Cache Server process terminated unexpectedly with exit status 1. Please
refer to the log file in /Users/jblum/pivdev/lab/Server2 for full details.
Exception in thread "main" java.lang.RuntimeException: An IO error occurred
while starting a Server in /Users/jblum/pivdev/lab/Server2 on
10.99.199.3[40404]: Network is unreachable; port (40404) is not available on
localhost.
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:735)
at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633)
at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:184)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost.
at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:127)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:688)
... 2 more
{code}
2. Second, the {{--locators}} option on {{start server}} is broken, hence the
reason I specified {{--server-port}} for both servers on start to avoid bind
Exceptions and used the {{--J}} option to specify the embedded Locator of
"Server1" with the {{gemfire.locators}} System property when starting
"Server2".
Otherwise, "Server2" starts in standalone mode!
was (Author: jblum):
A couple of "gems" about my {{start server}} command-lines in my _Gfsh_ session
above (previous comment)...
1. {{--disable-default-server}} does not prevent the "Geode Server" from trying
to start on the default {{CacheServer}} port (*40404*) anyway
When I attempt to start my second server ("Server2") the firs time if failed
with...
{code}
gfsh>start server --name=Server2 --log-level=config
--J=-Dgemfire.locators=localhost[10334] --disable-default-server
Starting a Geode Server in /Users/jblum/pivdev/lab/Server2...
The Cache Server process terminated unexpectedly with exit status 1. Please
refer to the log file in /Users/jblum/pivdev/lab/Server2 for full details.
Exception in thread "main" java.lang.RuntimeException: An IO error occurred
while starting a Server in /Users/jblum/pivdev/lab/Server2 on
10.99.199.3[40404]: Network is unreachable; port (40404) is not available on
localhost.
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:735)
at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633)
at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:184)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost.
at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:127)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:688)
... 2 more
{code}
2. Second, the {{--locators}} option on {{start server}} is broken, hence the
reason I specified {{--server-port}} for both servers on start to avoid bind
Exceptions and used the {{--J}} option to specify the embedded Locator of
"Server1" with the {{gemfire.locators}} System property when starting
"Server2".
Otherwise, "Server2" starts in standalone mode!
> 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
>Assignee: Jinmei Liao
>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 _Clu
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631107#comment-15631107
]
John Blum edited comment on GEODE-1986 at 11/3/16 1:08 AM:
---
This is still a bug!
New scenario...
1. Start Server 1 with an embedded Locator
2. Start another Server (Server 2) connecting to Server 1's embedded Locator.
Witness an exception...
{code:java}
[FORK] - java.io.EOFException: Locator at /127.0.0.1:11235 did not respond.
This is normal if the locator was shutdown. If it wasn't check its log for
exceptions.
[FORK] -at
org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:202)
[FORK] -at
org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:130)
[FORK] -at
org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:215)
[FORK] -at
org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
[FORK] -at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
[FORK] -at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
[FORK] -at
org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
[FORK] -at
org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
[FORK] -at
org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
[FORK] -at
org.springframework.data.gemfire.CacheFactoryBean.createCache(CacheFactoryBean.java:354)
[FORK] -at
org.springframework.data.gemfire.CacheFactoryBean.resolveCache(CacheFactoryBean.java:248)
[FORK] -at
org.springframework.data.gemfire.CacheFactoryBean.init(CacheFactoryBean.java:189)
[FORK] -at
org.springframework.data.gemfire.CacheFactoryBean.getObject(CacheFactoryBean.java:175)
[FORK] -at
org.springframework.data.gemfire.CacheFactoryBean.getObject(CacheFactoryBean.java:87)
[FORK] -at
org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:168)
[FORK] -at
org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:103)
[FORK] -at
org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1600)
[FORK] -at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:317)
[FORK] -at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
[FORK] -at
org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:207)
[FORK] -at
org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1128)
[FORK] -at
org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1056)
[FORK] -at
org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:835)
[FORK] -at
org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:741)
[FORK] -at
org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:467)
[FORK] -at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1128)
[FORK] -at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1023)
[FORK] -at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
[FORK] -at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
[FORK] -at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
[FORK] -at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
[FORK] -at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
[FORK] -at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
[FORK] -at
org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.autowireResource(CommonAnnotationBeanPostProcessor.jav
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631107#comment-15631107
]
John Blum edited comment on GEODE-1986 at 11/3/16 1:07 AM:
---
This is still a bug!
New scenario...
1. Start Server 1 with an embedded Locator
2. Start another Server (Server 2) connecting to Server 1's embedded Locator.
Witness an exception...
{code:java}
[FORK] - java.io.EOFException: Locator at /127.0.0.1:11235 did not respond.
This is normal if the locator was shutdown. If it wasn't check its log for
exceptions.
[FORK] -at
org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:202)
[FORK] -at
org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:130)
[FORK] -at
org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:215)
[FORK] -at
org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
[FORK] -at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
[FORK] -at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
[FORK] -at
org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
[FORK] -at
org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
[FORK] -at
org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
[FORK] - ...
[FORK] -
[FORK] - 2016-11-02 18:04:07,245 WARN
[org.springframework.context.annotation.AnnotationConfigApplicationContext] -
[FORK] - Exception in thread "main"
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name
'gemfireTemplateQueriesOnGroupedPooledClientCacheRegionsIntegrationTests.GemFireCacheServerTwoConfiguration':
Injection of resource dependencies failed; nested exception is
org.springframework.beans.factory.UnsatisfiedDependencyException: Error
creating bean with name 'Dogs' defined in
org.springframework.data.gemfire.GemfireTemplateQueriesOnGroupedPooledClientCacheRegionsIntegrationTests$GemFireCacheServerTwoConfiguration:
Unsatisfied dependency expressed through method 'dogsRegion' parameter 0;
nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'gemfireCache': FactoryBean threw exception on
object creation; nested exception is org.apache.geode.GemFireConfigException:
cluster configuration service not available
[FORK] -at
org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.postProcessPropertyValues(CommonAnnotationBeanPostProcessor.java:321)
[FORK] -at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1219)
[FORK] -at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
[FORK] -at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
[FORK] -at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
[FORK] -at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
[FORK] -at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
[FORK] -at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
[FORK] -at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:751)
[FORK] -at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:861)
[FORK] -at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:541)
[FORK] -at
org.springframework.context.annotation.AnnotationConfigApplicationContext.(AnnotationConfigApplicationContext.java:84)
[FORK] -at
org.springframework.data.gemfire.GemfireTemplateQueriesOnGroupedPooledClientCacheRegionsIntegrationTests$GemFireCacheServerTwoConfiguration.main(GemfireTemplateQueriesOnGroupedPooledClientCacheRegionsIntegrationTests.java:406)
[FORK] - Caused by:
org.springframework.beans.factory.UnsatisfiedDependencyException: Error
creating bean with name 'Dogs' defined in
org.springframework.data.gemfire.GemfireTemplateQueriesOnGroupedPooledClientCacheRegionsIntegrationTests$GemFireCacheServerTwoConfiguration:
Unsatisfied dependency expressed through method 'dogsRegion' par
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15572937#comment-15572937
]
John Blum edited comment on GEODE-1986 at 10/13/16 7:37 PM:
Great! The SDG build based on _Apache Geode_ {{1.1.0-incubating-SNAPSHOT}} now
passes with this fix. Thank you.
was (Author: jblum):
Great! The SDG build based _Apache Geode_ {{1.1.0-incubating-SNAPSHOT}} now
passes with this fix. Thank you.
> 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
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.0.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15572657#comment-15572657
]
John Blum edited comment on GEODE-1986 at 10/13/16 5:49 PM:
Sounds good. Let me verify the fix with another SDG build that initially
turned up this (original) problem. I assume this fix was checked into
{{develop}} and has been published to a nightly snapshot already?
I have been working to align SD Geode to the _Apache Geode_
{{1.0.0-incubating}} GA release, mostly based on the package rename, completed
as part of [GEODE-37].
Regarding...
{quote}
"Maybe your concern lies in the fact that currently there are limitations of
what cluster config service can do, so users would disable them to get what
they need to do."
{quote}
Mainly it boils down to limiting what the Cluster Configuration service sends a
peer member, which might happen to be an "application" peer cache member. It
might not be necessarily a bad thing to distribute the Security
Management/Configuration through CC, but if it means having to pick up all the
other configuration (Regions, DiskStore, Gateway definitions, etc; anything in
{{cache.xml}}), then this will be very problematic indeed. Again, I realize
the p2p application peer cache member scenarios does not reflect our
"recommended" architecture, but it does not stop users/customers from using it
that way and I have seen such deployments before.
was (Author: jblum):
Sounds good. Let me verify the fix with another SDG build that initially
turned up this (original) problem. I assume this fix was checked into
{{develop}} and has been published to a nightly snapshot already?
I have been working to align SD Geode to the _Apache Geode_
{{1.0.0-incubating}} GA release, mostly based on the package rename, completed
as part of [GEODE-37].
Regarding...
{quote}
"Maybe your concern lies in the fact that currently there are limitations of
what cluster config service can do, so users would disable them to get what
they need to do."
{quote}
Mainly it boils down to limiting what the Cluster Configuration service sends a
peer member, which might happen to be an "application" peer cache member. It
might not be necessarily a bad thing to distribute the Security
Management/Configuration through CC, but if it means having to pick up all the
other configuration (Regions, DiskStore, Gateway definitions, etc; anything in
{{cache.xml}}), then this will be very problematic indeed. Again, I realize
the p2p application peer cache member scenarios does not reflect our
"recommended" architecture, but it does stop users/customers from using it that
way and I have seen such deployments before.
> 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
>Assignee: Jinmei Liao
>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
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569869#comment-15569869
]
Jinmei Liao edited comment on GEODE-1986 at 10/13/16 6:23 AM:
--
The scenario you provided in the beginning of the bug is fixed by correcting
setting the "enable-cluster-configuration" flag when starting an embedded
locator. Cluster configuration is not a required service, if the locator does
not have cluster configuration service running, then regardless of its
security, a member can join with its own security manager. But if a locator has
cluster config running and is secured, any member without use-cluster-config
will be rejected. Are there other use cases that would fail with current
implementation? We will add it to our Dunit test suite to uncover it and fix it.
Also, without our current implementation, a server with correct credentials
and use SSL would successfully join a secured locator but itself can be
unprotected. Client can directly connect to that server without any credential
to get the data even though the locator is secured.
was (Author: jinmeiliao):
The scenario you provided in the beginning of the bug is fixed by correcting
setting the "enable-cluster-configuration" flag when starting an embedded
locator. Cluster configuration is not a required service, if the locator does
not have cluster configuration service running, then regardless of its
security, a member can join with its own security manager. But if a locator has
cluster config running and is secured, any member without use-cluster-config
will be rejected. Are there other use cases that would render this requirement
unacceptable? We will add it to our Dunit test suite to accommodate it.
Also, a server with correct credentials and use SSL will successfully join the
locator, but itself can be unprotected. Client can directly connect to that
server.
> 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
>Assignee: Jinmei Liao
>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.i
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569704#comment-15569704
]
John Blum edited comment on GEODE-1986 at 10/12/16 7:49 PM:
{quote}
2. If a locator is secured, a server who wants to join has to set
use-cluster-configuration to be true in order to join,
{quote}
No, this cannot (or rather, should not) be a requirement as it will adversely
affect peer cache application deployments, regardless of the
"recommended/suggested/whatever" architecture/topology suggested by the
(Pivotal) EA teams; it does (and will) not change how it is actually used in
certain use cases.
If it is requirement because the "security manager (configuration)" is obtained
from the Cluster Configuration (service running in the "secured" Locator) in
order to enforce the "same" (as you say in #1) security configuration on all
joining members of the cluster, then this is an unacceptable technical
limitation imposed on the users vs. an actual good, carefully thought-out,
design decision.
{quote}
"a server can join a secured locator but itself is not secured."
{quote}
Not likely, since it will fail the SSL handshake. I would assume that security
credentials (including configuration) would also need to be secured during
transit, therefore while authentication/authorization is not necessarily
required for secure transport (i.e. SSL) it would seem logical that SSL is a
prerequisite (or requirement) for auth.
was (Author: jblum):
{quote}
2. If a locator is secured, a server who wants to join has to set
use-cluster-configuration to be true in order to join,
{quote}
No, this cannot (or rather, should not) be a requirement as it will adversely
affect peer cache application deployments, regardless of the
"recommended/suggested/whatever" architecture/topology suggested by the
(Pivotal) EA teams; it does (and will) not change how it is actually used in
certain use cases.
If it is requirement because the "security manager (configuration)" is obtained
from the Cluster Configuration (service running in the "secured" Locator) in
order to enforce the "same" (as you say in #1) security configuration on all
joining members of the cluster, then this is an unacceptable technical
limitation imposed on the users vs. an actual good, carefully thought-out,
design decision.
{quote}
a server can join a secured locator but itself is not secured.
{quote}
Not likely, since it will fail the SSL handshake. I would assume that security
credentials (including configuration) would also need to be secured during
transit, therefore while authentication/authorization is not necessarily
required for secure transport (i.e. SSL) it would seem logical that SSL is a
prerequisite (or requirement) for auth.
> 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
>Assignee: Jinmei Liao
>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/geo
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569704#comment-15569704
]
John Blum edited comment on GEODE-1986 at 10/12/16 8:02 PM:
{quote}
2. If a locator is secured, a server who wants to join has to set
use-cluster-configuration to be true in order to join,
{quote}
No, this cannot (or rather, should not) be a requirement as it will adversely
affect peer cache application deployments, regardless of the
"recommended/suggested/whatever" architecture/topology suggested by the
(Pivotal) EA teams; it does (and will) not change how it is actually used in
certain use cases.
If it is requirement because the "security manager (configuration)" is obtained
from the Cluster Configuration (service running in the "secured" Locator) in
order to enforce the "same" (as you say in #1) security configuration on all
joining members of the cluster, then this is an unacceptable technical
limitation imposed on the users vs. an actual good, carefully thought-out,
design decision.
{quote}
"a server can join a secured locator but itself is not secured."
{quote}
Not likely, since it will fail the SSL handshake. I would assume that security
credentials (including configuration) would also need to be secured during
transit. Therefore, while authentication/authorization is not necessarily
required for secure transport (i.e. SSL), it would seem logical that SSL is a
prerequisite (or requirement) for auth.
was (Author: jblum):
{quote}
2. If a locator is secured, a server who wants to join has to set
use-cluster-configuration to be true in order to join,
{quote}
No, this cannot (or rather, should not) be a requirement as it will adversely
affect peer cache application deployments, regardless of the
"recommended/suggested/whatever" architecture/topology suggested by the
(Pivotal) EA teams; it does (and will) not change how it is actually used in
certain use cases.
If it is requirement because the "security manager (configuration)" is obtained
from the Cluster Configuration (service running in the "secured" Locator) in
order to enforce the "same" (as you say in #1) security configuration on all
joining members of the cluster, then this is an unacceptable technical
limitation imposed on the users vs. an actual good, carefully thought-out,
design decision.
{quote}
"a server can join a secured locator but itself is not secured."
{quote}
Not likely, since it will fail the SSL handshake. I would assume that security
credentials (including configuration) would also need to be secured during
transit, therefore while authentication/authorization is not necessarily
required for secure transport (i.e. SSL) it would seem logical that SSL is a
prerequisite (or requirement) for auth.
> 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
>Assignee: Jinmei Liao
>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/apach
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15566533#comment-15566533
]
Jinmei Liao edited comment on GEODE-1986 at 10/11/16 10:03 PM:
---
This was true before we put security-manager in the cluster configuration.
Before, if a member joins and has use-cluster-configuration set to false, it
won't request any cluster config, just starts up using its own config, joins
the cluster and all good. But in 9.0. PM wants:
1. If a locator is secured, a server who wants to join has to use the same
security manager as the locator.
2. If a locator is secured, a server who wants to join the secured server has
to set use-cluster-configuration to be true in order to join,
With these two new requirements, when a server joins, even it has
use-cluster-configuration set to be false, we still need to check if the
locator it's trying to join is a secured one or not, if it is, we need to
prevent it from starting up by throwing an exception, otherwise, we will let it
start. If we don't do that, a server can join a secured locator but itself is
not secured. This would leads to security leak.
was (Author: jinmeiliao):
This was true before we put security-manager in the cluster configuration.
Before, if a member joins and has use-cluster-configuration set to false, it
won't request any cluster config, just starts up using its own config, joins
the cluster and all good. But in 9.0. PM wants:
1. If a locator is secured, a server who wants to join the secured server has
to set use-cluster-configuration to be true in order to join,
2. If a locator is secured, a server who wants to join has to use the same
security manager as the locator.
With these two new requirements, when a server joins, even it has
use-cluster-configuration set to be false, we still need to check if the
locator it's trying to join is a secured one or not, if it is, we need to
prevent it from starting up by throwing an exception, otherwise, we will let it
start. If we don't do that, a server can join a secured locator but itself is
not secured. This would leads to security leak.
> 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
>Assignee: Jinmei Liao
>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)
>
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15566533#comment-15566533
]
Jinmei Liao edited comment on GEODE-1986 at 10/11/16 10:04 PM:
---
This was true before we put security-manager in the cluster configuration.
Before, if a member joins and has use-cluster-configuration set to false, it
won't request any cluster config, just starts up using its own config, joins
the cluster and all good. But in 9.0. PM wants:
1. If a locator is secured, a server who wants to join has to use the same
security manager as the locator.
2. If a locator is secured, a server who wants to join has to set
use-cluster-configuration to be true in order to join,
With these two new requirements, when a server joins, even it has
use-cluster-configuration set to be false, we still need to check if the
locator it's trying to join is a secured one or not, if it is, we need to
prevent it from starting up by throwing an exception, otherwise, we will let it
start. If we don't do that, a server can join a secured locator but itself is
not secured. This would leads to security leak.
was (Author: jinmeiliao):
This was true before we put security-manager in the cluster configuration.
Before, if a member joins and has use-cluster-configuration set to false, it
won't request any cluster config, just starts up using its own config, joins
the cluster and all good. But in 9.0. PM wants:
1. If a locator is secured, a server who wants to join has to use the same
security manager as the locator.
2. If a locator is secured, a server who wants to join the secured server has
to set use-cluster-configuration to be true in order to join,
With these two new requirements, when a server joins, even it has
use-cluster-configuration set to be false, we still need to check if the
locator it's trying to join is a secured one or not, if it is, we need to
prevent it from starting up by throwing an exception, otherwise, we will let it
start. If we don't do that, a server can join a secured locator but itself is
not secured. This would leads to security leak.
> 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
>Assignee: Jinmei Liao
>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.apa
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15566533#comment-15566533
]
Jinmei Liao edited comment on GEODE-1986 at 10/11/16 10:02 PM:
---
This was true before we put security-manager in the cluster configuration.
Before, if a member joins and has use-cluster-configuration set to false, it
won't request any cluster config, just starts up using its own config, joins
the cluster and all good. But in 9.0. PM wants:
1. If a locator is secured, a server who wants to join the secured server has
to set use-cluster-configuration to be true in order to join,
2. If a locator is secured, a server who wants to join has to use the same
security manager as the locator.
With these two new requirements, when a server joins, even it has
use-cluster-configuration set to be false, we still need to check if the
locator it's trying to join is a secured one or not, if it is, we need to
prevent it from starting up by throwing an exception, otherwise, we will let it
start. If we don't do that, a server can join a secured locator but itself is
not secured. This would leads to security leak.
was (Author: jinmeiliao):
This was true before we put security-manager in the cluster configuration.
Before, if a member joins and has use-cluster-configuration set to false, it
won't request any cluster config, just starts up using its own config, joins
the cluster and all good. But in 9.0. PM wants:
1. If security-manager is set on a locator, cluster service needs to be running.
2. If a locator is secured, a server who wants to join the secured server has
to set use-cluster-configuration to be true in order to join, this prevents the
server to be configured with a different security manager than the locator.
With these two new requirements, when a server joins, even it has
use-cluster-configuration set to be false, we still need to check if the
locator it's trying to join is a secured one or not, if it is, we need to
prevent it from starting up by throwing an exception, otherwise, we will let it
start. If we don't do that, a server can join a secured locator but itself is
not secured. This would leads to security leak.
> 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
>Assignee: Jinmei Liao
>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.GemFireCac
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564525#comment-15564525
]
John Blum edited comment on GEODE-1986 at 10/11/16 5:24 AM:
Inappropriately set the "_Fix Version/s_". It would be nice if this were fixed
prior to the *1.0.0-incubating (GA)* release.
was (Author: jblum):
In appropriately set the "Fix Version/s". It would be nice if this were fixed
prior to the 1.0.0-incubating (GA) release.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564233#comment-15564233
]
John Blum edited comment on GEODE-1986 at 10/11/16 3:29 AM:
As the logic is currently implemented, there appears to be no way to disable
the _Cluster Configuration_ service in Geode, and CC is not valid in all
contexts/UCs, much like the {{auto-reconnect}} feature.
was (Author: jblum):
As the logic is currently implemented, there appears to be no way to disable
the _Cluster Configuration_ service in Geode, and CC is not valid in all
contexts/UCs.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.0.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564233#comment-15564233
]
John Blum edited comment on GEODE-1986 at 10/11/16 3:28 AM:
As the logic is currently implemented, there appears to be no way to disable
the _Cluster Configuration_ service in Geode, and CC is not valid in all
contexts/UCs.
was (Author: jblum):
As it the logic is currently implemented, there appears to be no way to disable
the Cluster Configuration service in Geode, and CC is not valid in all
contexts/UCs.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.0.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564297#comment-15564297
]
John Blum edited comment on GEODE-1986 at 10/11/16 3:20 AM:
Attached example Application ({{App.java}}) starting an embedded peer Cache
instance to illustrate the problem.
was (Author: jblum):
Example Application starting an embedded peer Cache instance to illustrate the
problem.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.0.0-incubating
>
> Attachments: App.java
>
>
> A bug was introduced when the logic to fetch the Cluster Configuration
> meta-data from the Locator in the cluster by a member was refactored into
> it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564233#comment-15564233
]
John Blum edited comment on GEODE-1986 at 10/11/16 3:15 AM:
As it the logic is currently implemented, there appears to be no way to disable
the Cluster Configuration service in Geode, and CC is not valid in all
contexts/UCs.
was (Author: jblum):
As it is currently implemented, there appears to be no way to disable the
Cluster Configuration service, which is not valid in all contexts/UCs.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Critical
> Fix For: 1.0.0-incubating
>
>
> A bug was introduced when the logic to fetch the Cluster Configuration
> meta-data from the Locator in the cluster by a member was broken out into it
> is own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing (embedded application) deployments,
> particularly in situations where GemFire config, and especially, _Gfsh_ were
> not used to configure the cluster, which will be true when users upgrade
> existing clusters based on an earlier versions of Geode (namely GemFire <
> v7.0) and as well as Spring applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
