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