ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Bessonov (Jira)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-14800) Add technical ability to differentiate between create and update in configuration
Date Wed, 02 Jun 2021 14:39:00 GMT

     [ https://issues.apache.org/jira/browse/IGNITE-14800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ivan Bessonov updated IGNITE-14800:
-----------------------------------
    Description: 
{{org.apache.ignite.configuration.internal.DynamicConfiguration#change}} method (and its variants
in other classes) has a substantial disadvantage - it doesn't allow you to read current configuration
in lambdas to decide a new value for some other configurations.

Why is this the way it is? For simplicity of implementation, we immediately convert it to
{{InnerNode}} and only then pass into configuration changer. This means that we will apply
the same exact tree on every retry iteration.

This is bad during concurrent resources creation, if you create 2 resources with the same
name, then one of changes will be create and the other one is update. There is no way to tell
what will happen until it is already happened. Such behavior is not convenient if you create
SQL indexes or tables, for example, CREATE should not be silently converted to ALTER.

Other reason why it's bad - it complicates concurrent array fields updates. Makes it nearly
impossible.

What should we do to fix it?
 * CHANGE interfaces should extend VIEW interfaces. Lambda parameters should be available
for read and provide configuration snapshot that's currently being updated;
 * changing lambda should be applied on every retry. Only then we could guarantee that provided
configuration snapshots are valid;
 * consider using the same procedure for arbitrary configuration sources. This will save us
some code and will be handy in https://issues.apache.org/jira/browse/IGNITE-14645 implementation.

  was:
{{org.apache.ignite.configuration.internal.DynamicConfiguration#change}} method (and its variants
in other classes) has a substantial disadvantage - it doesn't allow you to read current configuration
in lambdas to decide a new value for some other configurations.

Why is this the way it is? For simplicity of implementation, we immediately convert it to
{{InnerNode}} and only then pass into configuration changer. This means that we will apply
the same exact tree on every retry iteration.

This is bad during concurrent resources creation, if you create 2 resources with the same
way, then one of changes will be create and the other one is update. There is no way to tell
what will happen until it is already happened. Such behavior is not convenient if you create
SQL indexes or tables, for example, CREATE should not be silently converted to ALTER.

Other reason why it's bad - it complicates concurrent array fields updates. Makes it nearly
impossible.

What should we do to fix it?
 * CHANGE interfaces should extend VIEW interfaces. Lambda parameters should be available
for read and provide configuration snapshot that's currently being updated;
 * changing lambda should be applied on every retry. Only then we could guarantee that provided
configuration snapshots are valid;
 * consider using the same procedure for arbitrary configuration sources. This will save us
some code and will be handy in https://issues.apache.org/jira/browse/IGNITE-14645 implementation.


> Add technical ability to differentiate between create and update in configuration
> ---------------------------------------------------------------------------------
>
>                 Key: IGNITE-14800
>                 URL: https://issues.apache.org/jira/browse/IGNITE-14800
>             Project: Ignite
>          Issue Type: Sub-task
>    Affects Versions: 3.0.0-alpha2
>            Reporter: Ivan Bessonov
>            Assignee: Ivan Bessonov
>            Priority: Major
>              Labels: ignite-3
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{org.apache.ignite.configuration.internal.DynamicConfiguration#change}} method (and
its variants in other classes) has a substantial disadvantage - it doesn't allow you to read
current configuration in lambdas to decide a new value for some other configurations.
> Why is this the way it is? For simplicity of implementation, we immediately convert it
to {{InnerNode}} and only then pass into configuration changer. This means that we will apply
the same exact tree on every retry iteration.
> This is bad during concurrent resources creation, if you create 2 resources with the
same name, then one of changes will be create and the other one is update. There is no way
to tell what will happen until it is already happened. Such behavior is not convenient if
you create SQL indexes or tables, for example, CREATE should not be silently converted to
ALTER.
> Other reason why it's bad - it complicates concurrent array fields updates. Makes it
nearly impossible.
> What should we do to fix it?
>  * CHANGE interfaces should extend VIEW interfaces. Lambda parameters should be available
for read and provide configuration snapshot that's currently being updated;
>  * changing lambda should be applied on every retry. Only then we could guarantee that
provided configuration snapshots are valid;
>  * consider using the same procedure for arbitrary configuration sources. This will save
us some code and will be handy in https://issues.apache.org/jira/browse/IGNITE-14645 implementation.



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

Mime
View raw message