ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Rakov <ivan.glu...@gmail.com>
Subject Re: Disable WAL for several cache groups within one exchange
Date Mon, 14 May 2018 16:27:38 GMT
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.glukos@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.glukos@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.govorukhin@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.glukos@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
>>>>>>>
>>>>>>>
>>>>>>>
>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message