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