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