geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Diane Hardman (JIRA)" <>
Subject [jira] [Commented] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
Date Fri, 04 Nov 2016 01:13:59 GMT


Diane Hardman commented on GEODE-1986:

I have confirmed tonight that John's original issue is fixed in the latest 9.0 build, specifically
you can now start the second server referencing the original embedded locator.
I have also confirmed, however, that John's second set of issues still exist, namely:
1. --disable-default-server does not prevent the "Geode Server" from trying to start on the
default CacheServer port (40404) anyway
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".

I think these issues should be in a separate Jira ticket and I would not hold up the 9.0 release
for these since there is a workaround.
John, do agree this is reasonable? 
Jinmei, do can you estimate the effort to fix these 2 issues?

> The Cluster Configuration Service must absolutely not be required to run Geode.
> -------------------------------------------------------------------------------
>                 Key: GEODE-1986
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>          Components: configuration
>    Affects Versions: 1.0.0-incubating
>            Reporter: John Blum
>            Assignee: Jinmei Liao
>            Priority: Critical
>              Labels: ClusterConfig, ClusterConfigurationService
>             Fix For: 1.1.0-incubating
>         Attachments:
> 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|]
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_
> This change is apparent from the removal of the [conditional check on the Geode System
property (1)|],
which is no longer present [here (2)|]
or possibly [here (3)|].
> 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
>  	at org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(
>  	at org.apache.geode.internal.cache.GemFireCacheImpl.initialize(
>  	at org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(
>  	at org.apache.geode.internal.cache.GemFireCacheImpl.create(
>  	at org.apache.geode.cache.CacheFactory.create(
>  	at org.apache.geode.cache.CacheFactory.create(
>  	... 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(
>  	at org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(
>  	... 47 more
> {code}

This message was sent by Atlassian JIRA

View raw message