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? >>>>>> >>
