I got your point. Since WAL state changes are linearized with exchange
worker queue, I think we can keep boolean return type even for new
multiple caches API.
Returned "true" will mean that WAL state of *at least one cache* was
actually changed by this call. Returned "false" will mean that requested
WAL state is exact match for existing WAL state (for the corresponding
topology version).
Method will keep its current semantics "If the same WAL state change is
requested more than once, only one call will return true".
Best Regards,
Ivan Rakov
On 14.05.2018 19:12, Anton Vinogradov wrote:
Ivan,
enableWal/disableWal will return false in case enabling/disabling was
caused not by this call.
For example it will return false in case wal already enabled/disabled.
Example:
boolean res1 = srv.cluster().enableWal(CACHE_NAME);
boolean res2 = srv.cluster().enableWal(CACHE_NAME);
assert res1;
assert !res2;
Vova,
Since you made final tuning for this solution, is there any special cases
when false can be returned?
пт, 11 мая 2018 г. в 18:39, Ivan Rakov <ivan.glu...@gmail.com>:
Agree about collections.
Regarding return type: it's a tricky question. Maybe author of this
feature may help.
Anton V., in which case enableWal/disableWal can return false?
Best Regards,
Ivan Rakov
On 11.05.2018 18:19, Vladimir Ozerov wrote:
Ivan,
This proven to be too hard to understand. It is better to have a lot
small
methods with clear and compact semantics. Also arrays are harder to
manage
than collections, users typically prefer the latest.
Also we need to think on what would be a result of this operation.
Current
methods with a single cache return true/false based on whether they
changed
something or not. Should we continue returning a single boolean for batch
operations as well?
On Fri, May 11, 2018 at 6:13 PM, Ivan Rakov <ivan.glu...@gmail.com>
wrote:
It would be six methods in total (3 for enabling, 3 for disabling).
What about accepting null in *enableWAL(String... caches)* as wildcard?
Best Regards,
Ivan Rakov
On 11.05.2018 17:52, Andrey Mashenkov wrote:
Ivan,
Huge +1 for this improvement.
I think we can have 2 overloaded method enableWal() with no args to
enable
WAL for all caches
and enableWAL(String... caches) for one or multiple caches. (and same
for
disable wal)
On Fri, May 11, 2018 at 5:25 PM, Dmitriy Govorukhin <
dmitriy.govoruk...@gmail.com> wrote:
Ivan,
Agree, if we have the batch method for cache create, we should have
the
ability to enable/disable WAL in the batch too.
On Fri, May 11, 2018 at 5:17 PM, Ivan Rakov <ivan.glu...@gmail.com>
wrote:
Igniters,
API method for disabling WAL in IgniteCluster accepts only one cache
name.
Every call triggers exchange and checkpoints cluster-wide - it takes
plenty
of time to disable/enable WAL for multiple caches.
I think, we should add option to disable/enable WAL for several
caches
with single command.
Thoughts?
--
Best Regards,
Ivan Rakov
