Soory.
I forgot two more methods
IgniteMXBean {
@Deprecated
public String clusterState();
public void clusterState(String state);
}
> 14 февр. 2020 г., в 17:50, Nikolay Izhikov <[email protected]>
> написал(а):
>
> 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.
>>>>>>
>>>>>
>>>
>>>
>
