Soory. I forgot two more methods
IgniteMXBean { @Deprecated public String clusterState(); public void clusterState(String state); } > 14 февр. 2020 г., в 17:50, Nikolay Izhikov <nizhikov....@gmail.com> > написал(а): > > 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, Вячеслав Коптилин <slava.kopti...@gmail.com> >> написал(а): >> >> 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 <nizhi...@apache.org>: >> >>> 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, Вячеслав Коптилин <slava.kopti...@gmail.com> >>> написал(а): >>>> >>>> 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 <vlads...@gmail.com>: >>>> >>>>> 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 < >>> alexey.goncha...@gmail.com >>>>>> : >>>>> >>>>>> 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. >>>>>> >>>>> >>> >>> >