Alexey. Having the way to silently vanish user data is even worse. So I’m strictly against removing —force flag.
> 24 марта 2020 г., в 10:16, Alexei Scherbakov <alexey.scherbak...@gmail.com> > написал(а): > > Nikolay, > > I'm on the same page with Ivan. > > Having "force" flag in public API as preposterous as having it in > System.exit. > For me it looks like badly designed API. > If a call to some method is dangerous it should be clearly specified in the > javadoc. > I'm also against some "temporary" API. > > We should: > > 1. Partially remove IGNITE-12701 except javadoc part. Note control.sh for a > long time has support for a confirmation on deactivation (interactive mode). > 2. IGNITE_REUSE_MEMORY_ON_DEACTIVATE=true already preserves memory content > after deactivation. We should start working on restoring page memory state > after subsequent reactivation. > 3. Describe current behavior for in-memory cache on deactivation in Ignite > documentation. > > > пн, 23 мар. 2020 г. в 21:22, Nikolay Izhikov <nizhi...@apache.org>: > >> Hello, Ivan. >> >>> Seems like we don't have a final agreement on whether we should add force >> flag to deactivation API. >> >> I think the only question is - Do we need —force flag in Java API or not. >> >> >>> As a final solution, I'd want to see behavior when all in-memory data is >> available after deactivation and further activation. >> >> Agree. >> >>> I believe it’s possible to don't deallocate memory >>> (like mentioned before, we already can achieve that with >> IGNITE_REUSE_MEMORY_ON_DEACTIVATE=true) and carefully reuse all loaded data >> pages on next activation and caches start. >> >> As far as I know, IGNITE_REUSE_MEMORY_ON_DEACTIVATE is for *other* purpose. >> Can you provide a simple reproducer when in-memory data not cleared on >> deactivation? >> >>> Considering this, do we really need to introduce force flag as a >> temporary precaution? >> >> My answer is yes we need it. >> Right now, we can’t prevent data loss on deactivation for in-memory caches. >> >> For me, the ultimate value of Ignite into real production environment is >> user data. >> If we have some cases when data is lost - we should avoid it as hard as we >> can. >> >> So, for now, this flag required. >> >>> I suggest to rollback [2] from AI master, stop working on [1] and focus >> on how to implement keeping in-memory data after the deactivation. >> >> I think we can remove —force flag only after implementation of keeping >> in-memory data on deactivation would be finished. >> If that happens before 2.9 then we can have clearer API. >> >>> 23 марта 2020 г., в 18:47, Ivan Rakov <ivan.glu...@gmail.com> >> написал(а): >>> >>> Folks, >>> >>> Let's revive this discussion until it's too late and all API changes are >>> merged to master [1]. >>> Seems like we don't have a final agreement on whether we should add force >>> flag to deactivation API. >>> >>> First of all, I think we are all on the same page that in-memory caches >>> data vanishing on deactivation is counter-intuitive and dangerous. As a >>> final solution, I'd want to see behavior when all in-memory data is >>> available after deactivation and further activation. I believe it's >>> possible to don't deallocate memory (like mentioned before, we already >> can >>> achieve that with IGNITE_REUSE_MEMORY_ON_DEACTIVATE=true) and carefully >>> reuse all loaded data pages on next activation and caches start. >>> >>> Also, this is a wider question, but: do we understand what cluster >>> deactivation is actually intended for? I can only think of two cases: >>> - graceful cluster shutdown: an ability to cut checkpoints and to end >>> transactional load consistently prior to further stop of all nodes >>> - blocking all API (both reads and writes) due to some maintenance >>> Neither of them requires forcefully clearing all in-memory data on >>> deactivation. If everyone agrees, from now on we should assume data >>> clearing as system design flaw that should be fixed, not as possible >>> scenario which we should support on the API level. >>> >>> Considering this, do we really need to introduce force flag as a >> temporary >>> precaution? I have at least two reasons against it: >>> 1) Once API was changed and released, we have to support it until the >> next >>> major release. If we all understand that data vanishing issue is >> fixable, I >>> believe we shouldn't engrave in the API flags that will become pointless. >>> 2) More personal one, but I'm against any force flags in the API. This >>> makes API harder to understand; more than that, the presence of such >> flags >>> just highlights that API is poorly designed. >>> >>> I suggest to rollback [2] from AI master, stop working on [1] and focus >> on >>> how to implement keeping in-memory data after the deactivation. >>> I think we can still require user consent for deactivation via control.sh >>> (it already requires --yes) and JMX. >>> >>> Thoughts? >>> >>> [1]: https://issues.apache.org/jira/browse/IGNITE-12614 >>> [2]: https://issues.apache.org/jira/browse/IGNITE-12701 >>> >>> -- >>> Ivan >>> >>> >>> On Tue, Mar 17, 2020 at 2:26 PM Vladimir Steshin <vlads...@gmail.com> >> wrote: >>> >>>> Nikolay, I think we should reconsider clearing at least system caches >>>> when deactivating. >>>> >>>> 17.03.2020 14:18, Nikolay Izhikov пишет: >>>>> Hello, Vladimir. >>>>> >>>>> I don’t get it. >>>>> >>>>> What is your proposal? >>>>> What we should do? >>>>> >>>>>> 17 марта 2020 г., в 14:11, Vladimir Steshin <vlads...@gmail.com> >>>> написал(а): >>>>>> >>>>>> Nikolay, hi. >>>>>> >>>>>>>>> And should be covered with the —force parameter we added. >>>>>> As fix for user cases - yes. My idea is to emphasize overall ability >> to >>>> lose various objects, not only data. Probably might be reconsidered in >>>> future. >>>>>> >>>>>> >>>>>> 17.03.2020 13:49, Nikolay Izhikov пишет: >>>>>>> Hello, Vladimir. >>>>>>> >>>>>>> If there is at lease one persistent data region then system data >>>> region also becomes persistent. >>>>>>> Your example applies only to pure in-memory clusters. >>>>>>> >>>>>>> And should be covered with the —force parameter we added. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>>> 17 марта 2020 г., в 13:45, Vladimir Steshin <vlads...@gmail.com> >>>> написал(а): >>>>>>>> >>>>>>>> Hi, all. >>>>>>>> >>>>>>>> Fixes for control.sh and the REST have been merged. Could anyone >> take >>>> a look to the previous email with an issue? Isn't this conductvery >> wierd? >>>>>>>> >>>> >> >> > > -- > > Best regards, > Alexei Scherbakov
