Vyacheslav.
Let’s see what we got for now:
```
Ignite {
@Deprecated
public boolean active();
@Deprecated
public void active(boolean active);
}
IgniteMXBean {
@Deprecated
public boolean active();
public void active(boolean active); //Please, note, this method is not
deprecated. It has the same implementation as Ignite#active(boolean)
}
IgniteCluster {
@Deprecated
public boolean active();
@Deprecated
public void active(boolean active);
public ClusterState state();
public void state(ClusterState newState) throws IgniteException;
}
```
This issue with the IgniteMXBean#active(boolean) - it has the same
implementation(IgniteKernal#active) as Ignite#active.
We can’t change IgniteMXBean#active without changing Ignite#active.
Moreover, for now, we already have an API mess for cluster activation.
If we introduce different behavior for the different interfaces(java, JMX) it
will confuse users even more.
> I see no reason to throw an exception in that case at least.
Users(and even Ignite PMCs) doesn’t expect that in-memory cache will be cleared
on deactivation.
I think we should notify users about this detail in very clear fashion -
require explicit confirmation for the operation.
> Anyway, this fact should be clearly stated in the Javadoc and documentation
> of course.
This is default requirement for the improvement.
It will be done.
> 14 февр. 2020 г., в 17:36, Вячеслав Коптилин <[email protected]>
> написал(а):
>
> Hello Nikolay,
>
>> Should public java API continue to silently clear in-memory caches?
> Let's assume that I have a mixed cluster with persistent cache and
> in-memory cache which is backed by 3-rd party persistence. I see no reason
> to throw an exception in that case at least.
> Anyway, this fact should be clearly stated in the Javadoc and documentation
> of course.
>
>> What is your suggestion for the API?
> I think we are talking about JMX methods. Am I correct? Is it possible to
> add new methods as follows: activateCluster()/deactivateCluster() and
> deprecate IgniteMXBean#active(boolean)?
> Does this make sense? Am I missing something?
>
> Thanks,
> S.
>
> пт, 14 февр. 2020 г. в 16:17, Nikolay Izhikov <[email protected]>:
>
>> Vyacheslav.
>>
>> What is your suggestion for the API?
>>
>> Single implementation for both Ignite#active(boolean) and
>> IgniteMXBean#active(boolean)
>> Should public java API continue to silently clears in-memory caches?
>>
>>
>>> 14 февр. 2020 г., в 15:56, Вячеслав Коптилин <[email protected]>
>> написал(а):
>>>
>>> Hello Vladimir,
>>>
>>>> adding a new method with force flag means old methods change their
>>> behavior:
>>> I don't think that changing the behavior of public API is the right way.
>>> Moreover, I agree with Alex that there is no need to introduce a
>>> "confirmation" flag to the java API.
>>>
>>> Thanks,
>>> S.
>>>
>>> пт, 14 февр. 2020 г. в 15:38, Vladimir Steshin <[email protected]>:
>>>
>>>> Alexey, adding a new method with force flag means old methods change
>> their
>>>> behavior: they are considered as executed without ‘force‘ flag and can
>> fail
>>>> to prevent data loss. Ignite and IgniteMXBean are different interfaces.
>>>> Unfortunately, they have same method
>>>>
>>>> void active(boolean active)
>>>>
>>>> When executed as IgniteMXBean it should fail if user can lose data. When
>>>> executed from code via interface Ignite probably not. To solve this I
>>>> suggest to add ‘force’ flag for every deactivation mode: CLI/JMX/REST
>> and
>>>> other API.
>>>>
>>>> пт, 14 февр. 2020 г. в 15:20, Alexey Goncharuk <
>> [email protected]
>>>>> :
>>>>
>>>>> Igniters,
>>>>>
>>>>> Do we really need the confirmation flag on the public API? I absolutely
>>>>> agree on the CLI and MXBean, but what is the reason for the flag in the
>>>>> API? It will be specified at the compile time anyway and does not
>> prevent
>>>>> any user error.
>>>>> From the implementation point of view I see no contradiction - we can
>> add
>>>>> the new method to the MXBean, but nothing forces us to add it to Ignite
>>>>> interface - those interfaces are not related.
>>>>>
>>>>
>>
>>
