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
