[ 
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 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)

Reply via email to