Looks like we need additional func for static caches, for example:
warmup(List<CacheConfiguration> cconf) it would be helpful for spring too.
>
>------- Forwarded message -------
>From: "Вячеслав Коптилин" < slava.kopti...@gmail.com >
>To: dev@ignite.apache.org
>Cc:
>Subject: Re: [DISCUSSION] Cache warmup
>Date: Mon, 27 Jul 2020 16:47:48 +0300
>
>Hello Kirill,
>
>Thanks a lot for driving this activity. If I am not mistaken, this
>discussion relates to IEP-40.
>
>> I suggest adding a warmup phase after recovery here [1] after [2], before
>discovery.
>This means that the user's thread, which starts Ignite via
>Ignition.start(), will wait for ana additional step - cache warm-up.
>I think this fact has to be clearly mentioned in our documentation (at
>Javadocat least) because this step can be time-consuming.
>
>> I suggest adding a new interface:
>I would change it a bit. First of all, it would be nice to place this
>interface to a public package and get rid of using GridCacheContext,
>which is an internal class and it should not leak to the public API in any
>case.
>Perhaps, this parameter is not needed at all or we should add some public
>abstraction instead of internal class.
>
>package org.apache.ignite.configuration;
>
>import org.apache.ignite.IgniteCheckedException;
>import org.apache.ignite.lang.IgniteFuture;
>
>public interface CacheWarmupper {
> /**
> * Warmup cache.
> *
> * @param cachename Cache name.
> * @return Future cache warmup.
> * @throws IgniteCheckedException If failed.
> */
> IgniteFuture<?> warmup(String cachename) throws
>IgniteCheckedException;
>}
>
>Thanks,
>S.
>
>пн, 27 июл. 2020 г. в 15:03, ткаленко кирилл < tkalkir...@yandex.ru >:
>
>> Now, after restarting node, we have only cold caches, which at first
>> requests to them will gradually load data from disks, which can slow down
>> first calls to them.
>> If node has more RAM than data on disk, then they can be loaded at start
>> "warmup", thereby solving the issue of slowdowns during first calls to
>> caches.
>>
>> I suggest adding a warmup phase after recovery here [1] after [2], before
>> descovery.
>>
>> I suggest adding a new interface:
>>
>> package org.apache.ignite.internal.processors.cache;
>>
>> import org.apache.ignite.IgniteCheckedException;
>> import org.apache.ignite.internal.IgniteInternalFuture;
>> import org.jetbrains.annotations.Nullable;
>>
>> /**
>> * Interface for warming up cache.
>> */
>> public interface CacheWarmup {
>> /**
>> * Warmup cache.
>> *
>> * @param cacheCtx Cache context.
>> * @return Future cache warmup.
>> * @throws IgniteCheckedException if failed.
>> */
>> @Nullable IgniteInternalFuture<?> process(GridCacheContext cacheCtx)
>> throws IgniteCheckedException;
>> }
>>
>> Which will allow to warm up caches in parallel and asynchronously. Warmup
>> phase will end after all IgniteInternalFuture for all caches isDone.
>>
>> Also adding the ability to customize via methods:
>> org.apache.ignite.configuration.IgniteConfiguration#setDefaultCacheWarmup
>> org.apache.ignite.configuration.CacheConfiguration#setCacheWarmup
>>
>> Which will allow for each cache to set implementation of cache warming
>> up,
>> both for a specific cache, and for all if necessary.
>>
>> I suggest adding an implementation of SequentialWarmup that will use [3].
>>
>> Questions, suggestions, comments?
>>
>> [1] -
>> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#afterLogicalUpdatesApplied
>> [2] -
>> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#restorePartitionStates
>> [3] -
>> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManager.CacheDataStore#preload
>>
