[
https://issues.apache.org/jira/browse/GEODE-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-2244:
-----------------------------
Component/s: configuration
> Cluster config start is async and may not be ready when requests start coming
> in
> --------------------------------------------------------------------------------
>
> Key: GEODE-2244
> URL: https://issues.apache.org/jira/browse/GEODE-2244
> Project: Geode
> Issue Type: Bug
> Components: configuration
> Affects Versions: 1.0.0-incubating
> Reporter: Kirk Lund
>
> This wouldn't be a problem but it looks like the locator hosting cluster
> config may reply to requests saying that it doesn't have cluster config
> enabled.
> The method in InternalLocator is startCache(DistributedSystem):
> {code:java}
> private void startCache(DistributedSystem ds) {
> GemFireCacheImpl gfc = GemFireCacheImpl.getInstance();
> if (gfc == null) {
> logger.info("Creating cache for locator.");
> this.myCache = new CacheFactory(ds.getProperties()).create();
> gfc = (GemFireCacheImpl) this.myCache;
> } else {
> logger.info("Using existing cache for locator.");
> ((InternalDistributedSystem)
> ds).handleResourceEvent(ResourceEvent.LOCATOR_START, this);
> }
> startJmxManagerLocationService(gfc);
> startSharedConfigurationService(gfc);
> }
> {code}
> The method startSharedConfigurationService hands off to a thread to load
> cluster config and use distributed lock service to become primary cluster
> config source. This was probably made async due to use of distributed lock
> service to keep startup responsive. Unfortunately, it opens up a race
> condition window -- if any requests come in before cluster config is ready,
> the locator will reply saying it doesn't have cluster config. I think some of
> our Flaky tests are hitting this race condition.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
