Ilya, This issue must be fixed for sure (don't think we should rewrite it from scratch).
Let's add TODO and warning comment referencing to this issue to the JavaDoc and also add the same warning to documentation pages. The reference to the issue will allow users to track the fixing progress. On Wed, 20 Jan 2021 at 22:39, Mikhail Cherkasov <mcherka...@gridgain.com> wrote: > > Hi Ilya, > > WAL disable is a very powerful feature that is widely adopted by users. > For sure we need to fix it, even if it means rewriting it. > The warning makes sense, in this case, we can even reduce the priority of > the issue, but anyway, it's at least a critical one, because it can lead to > data loss(and it does). > I would say, instead of a warning, we can do something more noticeable, > like method signature change like: > boolean disableWal(String cacheName, boolean > iReadJavaDockAndAwareOfTheRisk); - this one definitely will be noticed. > > Thanks, > Mike. > > On Wed, Jan 20, 2021 at 8:28 AM Ilya Kasnacheev <il...@apache.org> wrote: > > > Hello! > > > > We had this feature for a few versions, where you could do gnite.cluster(). > > disableWal() to temporarily disable WAL on a specific cache, involving a > > PME and checkpoint on every node. > > > > However, it became apparent that you cannot enable or disable WAL on any > > kind of unstable topology, at all: > > https://issues.apache.org/jira/browse/IGNITE-13976 > > > > You cannot even disable WAL while a baseline node is offline: When it comes > > back, it will not sync its WAL enabled status with the rest of the cluster, > > and all subsequent "WAL enable" or "WAL disable" operations will fail on > > that cache, with no clear way to recover this cache: > > > > ignite.close(); > > client.cluster().disableWal(CACHE_NAME); > > nodes.add(Ignition.start(igniteCfg(false, consistentId))); > > client.cluster().enableWal(CACHE_NAME); // will fail > > > > Even if this simple scenario is fixed, it seems that there are multiple > > failure scenarios if you try to add or remove a node in the middle of WAL > > state change operation. It does not seem that we have any expertise in wal > > disable/enable implementation right now, and I did not find a simple way of > > fixing it short of a full rewrite. > > > > Therefore, I propose that we should *(a) disable that feature* in 2.10 or* > > (b) give a clear warning *when it is used, and also mention in the > > documentation that it may only be used on stable topology. > > > > We may also want to re-mark this feature's API as @IgniteExperimental. > > I have lifted this ticket to be a Blocker. > > > > WDYT? > > > > Regards, > > > > > -- > Thanks, > Mikhail.
