[jira] [Commented] (IGNITE-15285) Properly split two ConfigurationManager instances

["Ivan Bessonov (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-15285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17399664#comment-17399664 ] 

Ivan Bessonov commented on IGNITE-15285:
----------------------------------------

[~ktkalenko@gridgain.com] looks good, thank you for the contribution!

> Properly split two ConfigurationManager instances
> -------------------------------------------------
>
>                 Key: IGNITE-15285
>                 URL: https://issues.apache.org/jira/browse/IGNITE-15285
>             Project: Ignite
>          Issue Type: Improvement
>    Affects Versions: 3.0.0-alpha2
>            Reporter: Ivan Bessonov
>            Assignee: Kirill Tkalenko
>            Priority: Major
>              Labels: iep-55, ignite-3
>             Fix For: 3.0.0-alpha3
>
>          Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Currently you can see "WARNING: Configuration listener has already been set." message on node start. That's not good, it means that one of configuration managers reuses the same storages and it doesn't work. It's a bad design and leads to weird bugs and unpredictable system behavior.
> The reason is this line of code:
> {code:java}
> cfgStorages.add(new DistributedConfigurationStorage(metaStorageMgr, vaultMgr));
> {code}
> What's need to be done is changing ConfigurationManager constructor so that it only takes one storage, not the list. Such decision will lead to two major consequences:
>  * REST module will have to deal with two ConfigurationManager instances. It's challenging to understand in advance the exact instance that it should use. Valid behavior should be discussed during implementation.
>  * Classes like ConfigurationRegistry and ConfigurationChanger operate with collections of storages. They should be refactored.
> Validators instances will probably be duplicated in both managers. It's hard to avoid duplication if we don't have ConfigurationManagerFactory or something, but having factory to create two well know instances is an overkill. Anyway, some approaches for deduplication should be discussed during implementation as well.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)