Hello, Vladimir.
I think we should do the following:
* Update Ignite documentation and write down the fact that in-memory cache
cleared on deactivation.
* Disallow, by default, deactivation of the cluster that has in-memory cache
with proper error message
«Your cluster has in-memory cache configured. During deactivation all
data from these caches will be cleared!»
* Add «—force» flag to deactivate command so administrator can force
deactivation for cluster that has both - persistent and in-memory caches
configured.
Changes in the source code should include:
1. JMX beans - IgniteMXBean.
2. Java API - Ignite#active and Ignite#cluster#state - because active method
have the same implementation as `IgniteMBBean#active`
3. CLI utility - control.sh
Igniters, what do you think?
> 13 февр. 2020 г., в 14:19, Vladimir Steshin <[email protected]> написал(а):
>
> Hello, everyone.
>
>
>
> I’d like to propose to make behavior of cluster deactivation the same
> independently on usage type: in code or manually with control.sh or JMX.
> Let’s put it in one place like IgniteCluster#state(ClusterState newState,
> boolean force) and require forced call for in-memory data.
>
> While I was doing the ticket I realized that the suggested previously
> solution cannot be complete. To prevent data loss via JMX I would need to
> stop executing IgniteMXBean#active(false). But this causes stopping of
> Ignite#active(false) too. The problem relies in single implementation for
> both interfaces in IgniteKernal#active(boolean). It has to act differently
> depending on where it is called from: JMX/CLI or code.
>
>
>
> Any thoughts?
>
> чт, 30 янв. 2020 г. в 13:08, Alexey Goncharuk <[email protected]>:
>
>> I agree on CLI and JMX because those interfaces can be used by a system
>> administrator and can be invoked by mistake.
>>
>> As for the Java API, personally, I find it strange to add 'force' or
>> 'confirm' flags to it because it is very unlikely that such an invocation
>> is done by mistake. Such mistakes are caught during the testing phase and
>> developers will end up hard-coding 'true' as a flag anyways.
>>
