Persistence per memory policy configuration

[Alexey Goncharuk]

Igniters,

I am currently reviewing a change allowing to enable persistence on a
per-memory-policy basis (thanks to K. Dudkov!) and have a question
regarding the changes in configuration.

The suggested change is to add a flag "persistenceEnabled" (defaults to
true) to the memory policy configuration. To keep configuration
compatibility, the logic is as follows:

If PersistentStoreConfiguration is set, then only memory policies with
persistenceEnabled=true flag will be persisted, which is consistent with
the current behavior. To disable persistence, persistenceEnabled flag
should be explicitly set to false.

If PersistentStoreConfiguration is not set, then all caches are stored
in-memory and persistenceEnabled is ignored.

While personally, I like this change, I would like to check if there are
any thoughts or objections to this approach.

--
Thanks,
AG

[Vladimir Ozerov]

As a user I would definitely prefer to control persistence through flag on
cache configuration. I do not even want to know what "memory policy" is.
E.g. CacheConfiguration.persistenceEnabled.

On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk <
[hidden email]> wrote:

> Igniters,
>
> I am currently reviewing a change allowing to enable persistence on a
> per-memory-policy basis (thanks to K. Dudkov!) and have a question
> regarding the changes in configuration.
>
> The suggested change is to add a flag "persistenceEnabled" (defaults to
> true) to the memory policy configuration. To keep configuration
> compatibility, the logic is as follows:
>
> If PersistentStoreConfiguration is set, then only memory policies with
> persistenceEnabled=true flag will be persisted, which is consistent with
> the current behavior. To disable persistence, persistenceEnabled flag
> should be explicitly set to false.
>
> If PersistentStoreConfiguration is not set, then all caches are stored
> in-memory and persistenceEnabled is ignored.
>
> While personally, I like this change, I would like to check if there are
> any thoughts or objections to this approach.
>
> --
> Thanks,
> AG
>

[Pavel Tupitsyn]

Agree with Vladimir.

Currently we enable persistence cluster-wide by setting
IgniteConfiguration.persistentStoreConfiguration.
Ideally CacheConfiguration.persistenceEnabled should be the only setting I
need to set.

Thanks,
Pavel

On Tue, Sep 12, 2017 at 12:28 PM, Vladimir Ozerov <[hidden email]>
wrote:

> As a user I would definitely prefer to control persistence through flag on
> cache configuration. I do not even want to know what "memory policy" is.
> E.g. CacheConfiguration.persistenceEnabled.
>
> On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk <
> [hidden email]> wrote:
>
> > Igniters,
> >
> > I am currently reviewing a change allowing to enable persistence on a
> > per-memory-policy basis (thanks to K. Dudkov!) and have a question
> > regarding the changes in configuration.
> >
> > The suggested change is to add a flag "persistenceEnabled" (defaults to
> > true) to the memory policy configuration. To keep configuration
> > compatibility, the logic is as follows:
> >
> > If PersistentStoreConfiguration is set, then only memory policies with
> > persistenceEnabled=true flag will be persisted, which is consistent with
> > the current behavior. To disable persistence, persistenceEnabled flag
> > should be explicitly set to false.
> >
> > If PersistentStoreConfiguration is not set, then all caches are stored
> > in-memory and persistenceEnabled is ignored.
> >
> > While personally, I like this change, I would like to check if there are
> > any thoughts or objections to this approach.
> >
> > --
> > Thanks,
> > AG
> >
>

[Alexey Goncharuk]

This is possible, but then if two caches belong to the same memory policy,
they must be both either persistence-enabled or persistence-disabled. We
can add this validation, but I think this will lead to a greater confusion
for a user.

2017-09-12 12:34 GMT+03:00 Pavel Tupitsyn <[hidden email]>:

> Agree with Vladimir.
>
> Currently we enable persistence cluster-wide by setting
> IgniteConfiguration.persistentStoreConfiguration.
> Ideally CacheConfiguration.persistenceEnabled should be the only setting I
> need to set.
>
> Thanks,
> Pavel
>
> On Tue, Sep 12, 2017 at 12:28 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > As a user I would definitely prefer to control persistence through flag
> on
> > cache configuration. I do not even want to know what "memory policy" is.
> > E.g. CacheConfiguration.persistenceEnabled.
> >
> > On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk <
> > [hidden email]> wrote:
> >
> > > Igniters,
> > >
> > > I am currently reviewing a change allowing to enable persistence on a
> > > per-memory-policy basis (thanks to K. Dudkov!) and have a question
> > > regarding the changes in configuration.
> > >
> > > The suggested change is to add a flag "persistenceEnabled" (defaults to
> > > true) to the memory policy configuration. To keep configuration
> > > compatibility, the logic is as follows:
> > >
> > > If PersistentStoreConfiguration is set, then only memory policies with
> > > persistenceEnabled=true flag will be persisted, which is consistent
> with
> > > the current behavior. To disable persistence, persistenceEnabled flag
> > > should be explicitly set to false.
> > >
> > > If PersistentStoreConfiguration is not set, then all caches are stored
> > > in-memory and persistenceEnabled is ignored.
> > >
> > > While personally, I like this change, I would like to check if there
> are
> > > any thoughts or objections to this approach.
> > >
> > > --
> > > Thanks,
> > > AG
> > >
> >
>

[Vladimir Ozerov]

Alex,

Can we have two default memory policies - one for in-memory and another one
for persistence cases?

On Tue, Sep 12, 2017 at 12:40 PM, Alexey Goncharuk <
[hidden email]> wrote:

> This is possible, but then if two caches belong to the same memory policy,
> they must be both either persistence-enabled or persistence-disabled. We
> can add this validation, but I think this will lead to a greater confusion
> for a user.
>
> 2017-09-12 12:34 GMT+03:00 Pavel Tupitsyn <[hidden email]>:
>
> > Agree with Vladimir.
> >
> > Currently we enable persistence cluster-wide by setting
> > IgniteConfiguration.persistentStoreConfiguration.
> > Ideally CacheConfiguration.persistenceEnabled should be the only
> setting I
> > need to set.
> >
> > Thanks,
> > Pavel
> >
> > On Tue, Sep 12, 2017 at 12:28 PM, Vladimir Ozerov <[hidden email]>
> > wrote:
> >
> > > As a user I would definitely prefer to control persistence through flag
> > on
> > > cache configuration. I do not even want to know what "memory policy"
> is.
> > > E.g. CacheConfiguration.persistenceEnabled.
> > >
> > > On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk <
> > > [hidden email]> wrote:
> > >
> > > > Igniters,
> > > >
> > > > I am currently reviewing a change allowing to enable persistence on a
> > > > per-memory-policy basis (thanks to K. Dudkov!) and have a question
> > > > regarding the changes in configuration.
> > > >
> > > > The suggested change is to add a flag "persistenceEnabled" (defaults
> to
> > > > true) to the memory policy configuration. To keep configuration
> > > > compatibility, the logic is as follows:
> > > >
> > > > If PersistentStoreConfiguration is set, then only memory policies
> with
> > > > persistenceEnabled=true flag will be persisted, which is consistent
> > with
> > > > the current behavior. To disable persistence, persistenceEnabled flag
> > > > should be explicitly set to false.
> > > >
> > > > If PersistentStoreConfiguration is not set, then all caches are
> stored
> > > > in-memory and persistenceEnabled is ignored.
> > > >
> > > > While personally, I like this change, I would like to check if there
> > are
> > > > any thoughts or objections to this approach.
> > > >
> > > > --
> > > > Thanks,
> > > > AG
> > > >
> > >
> >
>

[Alexey Goncharuk]

We surely can, but:
 * we should then have two configuration settings for default memory policy
size (one in-memory and one persisted)
 * a user still may configure multiple custom memory policies. In this
case, the requirement to have this flag the same in a memory policy is
still valid, so a user still can get exceptions.

2017-09-12 12:44 GMT+03:00 Vladimir Ozerov <[hidden email]>:

> Alex,
>
> Can we have two default memory policies - one for in-memory and another one
> for persistence cases?
>
> On Tue, Sep 12, 2017 at 12:40 PM, Alexey Goncharuk <
> [hidden email]> wrote:
>
> > This is possible, but then if two caches belong to the same memory
> policy,
> > they must be both either persistence-enabled or persistence-disabled. We
> > can add this validation, but I think this will lead to a greater
> confusion
> > for a user.
> >
> > 2017-09-12 12:34 GMT+03:00 Pavel Tupitsyn <[hidden email]>:
> >
> > > Agree with Vladimir.
> > >
> > > Currently we enable persistence cluster-wide by setting
> > > IgniteConfiguration.persistentStoreConfiguration.
> > > Ideally CacheConfiguration.persistenceEnabled should be the only
> > setting I
> > > need to set.
> > >
> > > Thanks,
> > > Pavel
> > >
> > > On Tue, Sep 12, 2017 at 12:28 PM, Vladimir Ozerov <
> [hidden email]>
> > > wrote:
> > >
> > > > As a user I would definitely prefer to control persistence through
> flag
> > > on
> > > > cache configuration. I do not even want to know what "memory policy"
> > is.
> > > > E.g. CacheConfiguration.persistenceEnabled.
> > > >
> > > > On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk <
> > > > [hidden email]> wrote:
> > > >
> > > > > Igniters,
> > > > >
> > > > > I am currently reviewing a change allowing to enable persistence
> on a
> > > > > per-memory-policy basis (thanks to K. Dudkov!) and have a question
> > > > > regarding the changes in configuration.
> > > > >
> > > > > The suggested change is to add a flag "persistenceEnabled"
> (defaults
> > to
> > > > > true) to the memory policy configuration. To keep configuration
> > > > > compatibility, the logic is as follows:
> > > > >
> > > > > If PersistentStoreConfiguration is set, then only memory policies
> > with
> > > > > persistenceEnabled=true flag will be persisted, which is consistent
> > > with
> > > > > the current behavior. To disable persistence, persistenceEnabled
> flag
> > > > > should be explicitly set to false.
> > > > >
> > > > > If PersistentStoreConfiguration is not set, then all caches are
> > stored
> > > > > in-memory and persistenceEnabled is ignored.
> > > > >
> > > > > While personally, I like this change, I would like to check if
> there
> > > are
> > > > > any thoughts or objections to this approach.
> > > > >
> > > > > --
> > > > > Thanks,
> > > > > AG
> > > > >
> > > >
> > >
> >
>

[Pavel Tupitsyn]

Can we leave the default policy as is, but clone it with persistence
enabled on demand?

E.g:
- user starts Ignite with default config
- createCache without persistence - use default policy
- createCache with persistence - clone default policy with enabled
persistence and some predefined postfix
- createCache without persistence - use default policy
- createCache with persistence - reuse cloned policy

etc etc.

We can think of CacheConfiguration.persistenceEnabled as an override.

On Tue, Sep 12, 2017 at 12:57 PM, Alexey Goncharuk <
[hidden email]> wrote:

> We surely can, but:
>  * we should then have two configuration settings for default memory policy
> size (one in-memory and one persisted)
>  * a user still may configure multiple custom memory policies. In this
> case, the requirement to have this flag the same in a memory policy is
> still valid, so a user still can get exceptions.
>
> 2017-09-12 12:44 GMT+03:00 Vladimir Ozerov <[hidden email]>:
>
> > Alex,
> >
> > Can we have two default memory policies - one for in-memory and another
> one
> > for persistence cases?
> >
> > On Tue, Sep 12, 2017 at 12:40 PM, Alexey Goncharuk <
> > [hidden email]> wrote:
> >
> > > This is possible, but then if two caches belong to the same memory
> > policy,
> > > they must be both either persistence-enabled or persistence-disabled.
> We
> > > can add this validation, but I think this will lead to a greater
> > confusion
> > > for a user.
> > >
> > > 2017-09-12 12:34 GMT+03:00 Pavel Tupitsyn <[hidden email]>:
> > >
> > > > Agree with Vladimir.
> > > >
> > > > Currently we enable persistence cluster-wide by setting
> > > > IgniteConfiguration.persistentStoreConfiguration.
> > > > Ideally CacheConfiguration.persistenceEnabled should be the only
> > > setting I
> > > > need to set.
> > > >
> > > > Thanks,
> > > > Pavel
> > > >
> > > > On Tue, Sep 12, 2017 at 12:28 PM, Vladimir Ozerov <
> > [hidden email]>
> > > > wrote:
> > > >
> > > > > As a user I would definitely prefer to control persistence through
> > flag
> > > > on
> > > > > cache configuration. I do not even want to know what "memory
> policy"
> > > is.
> > > > > E.g. CacheConfiguration.persistenceEnabled.
> > > > >
> > > > > On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk <
> > > > > [hidden email]> wrote:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > I am currently reviewing a change allowing to enable persistence
> > on a
> > > > > > per-memory-policy basis (thanks to K. Dudkov!) and have a
> question
> > > > > > regarding the changes in configuration.
> > > > > >
> > > > > > The suggested change is to add a flag "persistenceEnabled"
> > (defaults
> > > to
> > > > > > true) to the memory policy configuration. To keep configuration
> > > > > > compatibility, the logic is as follows:
> > > > > >
> > > > > > If PersistentStoreConfiguration is set, then only memory policies
> > > with
> > > > > > persistenceEnabled=true flag will be persisted, which is
> consistent
> > > > with
> > > > > > the current behavior. To disable persistence, persistenceEnabled
> > flag
> > > > > > should be explicitly set to false.
> > > > > >
> > > > > > If PersistentStoreConfiguration is not set, then all caches are
> > > stored
> > > > > > in-memory and persistenceEnabled is ignored.
> > > > > >
> > > > > > While personally, I like this change, I would like to check if
> > there
> > > > are
> > > > > > any thoughts or objections to this approach.
> > > > > >
> > > > > > --
> > > > > > Thanks,
> > > > > > AG
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Alexey Goncharuk]

This may work. But I do not like any implicit memory policy cloning because
this will double the expected memory consumption and result in questions
"why does my Ignite take 2x more memory when I enable persistence" from
users.

I think if we go with "persistence per cache" path, we must just enforce
the correct configuration and let users configure the rest. Any implicit
'magic' will lead to confusion.

2017-09-12 13:10 GMT+03:00 Pavel Tupitsyn <[hidden email]>:

> Can we leave the default policy as is, but clone it with persistence
> enabled on demand?
>
> E.g:
> - user starts Ignite with default config
> - createCache without persistence - use default policy
> - createCache with persistence - clone default policy with enabled
> persistence and some predefined postfix
> - createCache without persistence - use default policy
> - createCache with persistence - reuse cloned policy
>
> etc etc.
>
> We can think of CacheConfiguration.persistenceEnabled as an override.
>
> On Tue, Sep 12, 2017 at 12:57 PM, Alexey Goncharuk <
> [hidden email]> wrote:
>
> > We surely can, but:
> >  * we should then have two configuration settings for default memory
> policy
> > size (one in-memory and one persisted)
> >  * a user still may configure multiple custom memory policies. In this
> > case, the requirement to have this flag the same in a memory policy is
> > still valid, so a user still can get exceptions.
> >
> > 2017-09-12 12:44 GMT+03:00 Vladimir Ozerov <[hidden email]>:
> >
> > > Alex,
> > >
> > > Can we have two default memory policies - one for in-memory and another
> > one
> > > for persistence cases?
> > >
> > > On Tue, Sep 12, 2017 at 12:40 PM, Alexey Goncharuk <
> > > [hidden email]> wrote:
> > >
> > > > This is possible, but then if two caches belong to the same memory
> > > policy,
> > > > they must be both either persistence-enabled or persistence-disabled.
> > We
> > > > can add this validation, but I think this will lead to a greater
> > > confusion
> > > > for a user.
> > > >
> > > > 2017-09-12 12:34 GMT+03:00 Pavel Tupitsyn <[hidden email]>:
> > > >
> > > > > Agree with Vladimir.
> > > > >
> > > > > Currently we enable persistence cluster-wide by setting
> > > > > IgniteConfiguration.persistentStoreConfiguration.
> > > > > Ideally CacheConfiguration.persistenceEnabled should be the only
> > > > setting I
> > > > > need to set.
> > > > >
> > > > > Thanks,
> > > > > Pavel
> > > > >
> > > > > On Tue, Sep 12, 2017 at 12:28 PM, Vladimir Ozerov <
> > > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > As a user I would definitely prefer to control persistence
> through
> > > flag
> > > > > on
> > > > > > cache configuration. I do not even want to know what "memory
> > policy"
> > > > is.
> > > > > > E.g. CacheConfiguration.persistenceEnabled.
> > > > > >
> > > > > > On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk <
> > > > > > [hidden email]> wrote:
> > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > I am currently reviewing a change allowing to enable
> persistence
> > > on a
> > > > > > > per-memory-policy basis (thanks to K. Dudkov!) and have a
> > question
> > > > > > > regarding the changes in configuration.
> > > > > > >
> > > > > > > The suggested change is to add a flag "persistenceEnabled"
> > > (defaults
> > > > to
> > > > > > > true) to the memory policy configuration. To keep configuration
> > > > > > > compatibility, the logic is as follows:
> > > > > > >
> > > > > > > If PersistentStoreConfiguration is set, then only memory
> policies
> > > > with
> > > > > > > persistenceEnabled=true flag will be persisted, which is
> > consistent
> > > > > with
> > > > > > > the current behavior. To disable persistence,
> persistenceEnabled
> > > flag
> > > > > > > should be explicitly set to false.
> > > > > > >
> > > > > > > If PersistentStoreConfiguration is not set, then all caches are
> > > > stored
> > > > > > > in-memory and persistenceEnabled is ignored.
> > > > > > >
> > > > > > > While personally, I like this change, I would like to check if
> > > there
> > > > > are
> > > > > > > any thoughts or objections to this approach.
> > > > > > >
> > > > > > > --
> > > > > > > Thanks,
> > > > > > > AG
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[yzhdanov]

Agree that implicit actions are always source of issues of different kinds.

Alex, having persistence enabled by default does not seem to be a good idea.

>I think if we go with "persistence per cache" path, we must just enforce the
correct configuration and let users configure the rest

What do you mean by enforce? What if user mixes persisted and in-mem caches?

--Yakov

[Alexey Goncharuk]

Yakov,

The default=true will be used only if the PersistentStoreConfiguration is
set in the IgniteConfiguration, this is done only to maintain configuration
compatibility.

A user is allowed to use persisted and in-memory caches, he will be only
forced to put them into separate memory policies.

2017-09-12 13:39 GMT+03:00 Yakov Zhdanov <[hidden email]>:

> Agree that implicit actions are always source of issues of different kinds.
>
> Alex, having persistence enabled by default does not seem to be a good
> idea.
>
> >I think if we go with "persistence per cache" path, we must just enforce
> the
> correct configuration and let users configure the rest
>
> What do you mean by enforce? What if user mixes persisted and in-mem
> caches?
>
> --Yakov
>

[dmagda]

While we are contemplating the best way to introduce this feature I have a side note to consider. Can the user enable CacheStore (RDBMS, Cassandra) for caches that are not persisted in Ignite Persistence? That’s one of the use cases I hear a lot about - some of the caches need persisted in Ignite Persistence while the rest in a 3rd party storage.

Think it makes sense to support this use case as a part of this work.

—
Denis

> On Sep 12, 2017, at 2:24 AM, Alexey Goncharuk <[hidden email]> wrote:
>
> Igniters,
>
> I am currently reviewing a change allowing to enable persistence on a
> per-memory-policy basis (thanks to K. Dudkov!) and have a question
> regarding the changes in configuration.
>
> The suggested change is to add a flag "persistenceEnabled" (defaults to
> true) to the memory policy configuration. To keep configuration
> compatibility, the logic is as follows:
>
> If PersistentStoreConfiguration is set, then only memory policies with
> persistenceEnabled=true flag will be persisted, which is consistent with
> the current behavior. To disable persistence, persistenceEnabled flag
> should be explicitly set to false.
>
> If PersistentStoreConfiguration is not set, then all caches are stored
> in-memory and persistenceEnabled is ignored.
>
> While personally, I like this change, I would like to check if there are
> any thoughts or objections to this approach.
>
> --
> Thanks,
> AG

[dsetrakyan]

To extend on the idea of 2 different policies for memory and persistence,
can we have 2 completely different configuration classes?

 - MemoryPolicy
 - PersistentMemoryPolicy (extends MemoryPolicy?)

Every cache should be associated with either MemoryPolicy or
PersistentMemoryPolicy, but not both. By default, caches on startup are
associated with default MemoryPolicy. Users can always change it to some
PersistentMemoryPolicy, if persistence needs to be enabled.

If we agree on the above, do we really need a persistenceEnabled flag at
all?

D.

On Tue, Sep 12, 2017 at 2:57 AM, Alexey Goncharuk <
[hidden email]> wrote:

> We surely can, but:
>  * we should then have two configuration settings for default memory policy
> size (one in-memory and one persisted)
>  * a user still may configure multiple custom memory policies. In this
> case, the requirement to have this flag the same in a memory policy is
> still valid, so a user still can get exceptions.
>
> 2017-09-12 12:44 GMT+03:00 Vladimir Ozerov <[hidden email]>:
>
> > Alex,
> >
> > Can we have two default memory policies - one for in-memory and another
> one
> > for persistence cases?
> >
> > On Tue, Sep 12, 2017 at 12:40 PM, Alexey Goncharuk <
> > [hidden email]> wrote:
> >
> > > This is possible, but then if two caches belong to the same memory
> > policy,
> > > they must be both either persistence-enabled or persistence-disabled.
> We
> > > can add this validation, but I think this will lead to a greater
> > confusion
> > > for a user.
> > >
> > > 2017-09-12 12:34 GMT+03:00 Pavel Tupitsyn <[hidden email]>:
> > >
> > > > Agree with Vladimir.
> > > >
> > > > Currently we enable persistence cluster-wide by setting
> > > > IgniteConfiguration.persistentStoreConfiguration.
> > > > Ideally CacheConfiguration.persistenceEnabled should be the only
> > > setting I
> > > > need to set.
> > > >
> > > > Thanks,
> > > > Pavel
> > > >
> > > > On Tue, Sep 12, 2017 at 12:28 PM, Vladimir Ozerov <
> > [hidden email]>
> > > > wrote:
> > > >
> > > > > As a user I would definitely prefer to control persistence through
> > flag
> > > > on
> > > > > cache configuration. I do not even want to know what "memory
> policy"
> > > is.
> > > > > E.g. CacheConfiguration.persistenceEnabled.
> > > > >
> > > > > On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk <
> > > > > [hidden email]> wrote:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > I am currently reviewing a change allowing to enable persistence
> > on a
> > > > > > per-memory-policy basis (thanks to K. Dudkov!) and have a
> question
> > > > > > regarding the changes in configuration.
> > > > > >
> > > > > > The suggested change is to add a flag "persistenceEnabled"
> > (defaults
> > > to
> > > > > > true) to the memory policy configuration. To keep configuration
> > > > > > compatibility, the logic is as follows:
> > > > > >
> > > > > > If PersistentStoreConfiguration is set, then only memory policies
> > > with
> > > > > > persistenceEnabled=true flag will be persisted, which is
> consistent
> > > > with
> > > > > > the current behavior. To disable persistence, persistenceEnabled
> > flag
> > > > > > should be explicitly set to false.
> > > > > >
> > > > > > If PersistentStoreConfiguration is not set, then all caches are
> > > stored
> > > > > > in-memory and persistenceEnabled is ignored.
> > > > > >
> > > > > > While personally, I like this change, I would like to check if
> > there
> > > > are
> > > > > > any thoughts or objections to this approach.
> > > > > >
> > > > > > --
> > > > > > Thanks,
> > > > > > AG
> > > > > >
> > > > >
> > > >
> > >
> >
>

[dmagda]

I would go for PersistentMemoryPolicyConfiguration way if it will be expanded by storage related settings furthers.

For instance, from the discussion on @user I see a raising demand for the storage maximum size. If it’s reached the data will be evicted from there too. Just as an example.

—
Denis

> On Sep 12, 2017, at 2:01 PM, Dmitriy Setrakyan <[hidden email]> wrote:
>
> To extend on the idea of 2 different policies for memory and persistence,
> can we have 2 completely different configuration classes?
>
> - MemoryPolicy
> - PersistentMemoryPolicy (extends MemoryPolicy?)
>
> Every cache should be associated with either MemoryPolicy or
> PersistentMemoryPolicy, but not both. By default, caches on startup are
> associated with default MemoryPolicy. Users can always change it to some
> PersistentMemoryPolicy, if persistence needs to be enabled.
>
> If we agree on the above, do we really need a persistenceEnabled flag at
> all?
>
> D.
>
> On Tue, Sep 12, 2017 at 2:57 AM, Alexey Goncharuk <
> [hidden email]> wrote:
>
>> We surely can, but:
>> * we should then have two configuration settings for default memory policy
>> size (one in-memory and one persisted)
>> * a user still may configure multiple custom memory policies. In this
>> case, the requirement to have this flag the same in a memory policy is
>> still valid, so a user still can get exceptions.
>>
>> 2017-09-12 12:44 GMT+03:00 Vladimir Ozerov <[hidden email]>:
>>
>>> Alex,
>>>
>>> Can we have two default memory policies - one for in-memory and another
>> one
>>> for persistence cases?
>>>
>>> On Tue, Sep 12, 2017 at 12:40 PM, Alexey Goncharuk <
>>> [hidden email]> wrote:
>>>
>>>> This is possible, but then if two caches belong to the same memory
>>> policy,
>>>> they must be both either persistence-enabled or persistence-disabled.
>> We
>>>> can add this validation, but I think this will lead to a greater
>>> confusion
>>>> for a user.
>>>>
>>>> 2017-09-12 12:34 GMT+03:00 Pavel Tupitsyn <[hidden email]>:
>>>>
>>>>> Agree with Vladimir.
>>>>>
>>>>> Currently we enable persistence cluster-wide by setting
>>>>> IgniteConfiguration.persistentStoreConfiguration.
>>>>> Ideally CacheConfiguration.persistenceEnabled should be the only
>>>> setting I
>>>>> need to set.
>>>>>
>>>>> Thanks,
>>>>> Pavel
>>>>>
>>>>> On Tue, Sep 12, 2017 at 12:28 PM, Vladimir Ozerov <
>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>>> As a user I would definitely prefer to control persistence through
>>> flag
>>>>> on
>>>>>> cache configuration. I do not even want to know what "memory
>> policy"
>>>> is.
>>>>>> E.g. CacheConfiguration.persistenceEnabled.
>>>>>>
>>>>>> On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>> Igniters,
>>>>>>>
>>>>>>> I am currently reviewing a change allowing to enable persistence
>>> on a
>>>>>>> per-memory-policy basis (thanks to K. Dudkov!) and have a
>> question
>>>>>>> regarding the changes in configuration.
>>>>>>>
>>>>>>> The suggested change is to add a flag "persistenceEnabled"
>>> (defaults
>>>> to
>>>>>>> true) to the memory policy configuration. To keep configuration
>>>>>>> compatibility, the logic is as follows:
>>>>>>>
>>>>>>> If PersistentStoreConfiguration is set, then only memory policies
>>>> with
>>>>>>> persistenceEnabled=true flag will be persisted, which is
>> consistent
>>>>> with
>>>>>>> the current behavior. To disable persistence, persistenceEnabled
>>> flag
>>>>>>> should be explicitly set to false.
>>>>>>>
>>>>>>> If PersistentStoreConfiguration is not set, then all caches are
>>>> stored
>>>>>>> in-memory and persistenceEnabled is ignored.
>>>>>>>
>>>>>>> While personally, I like this change, I would like to check if
>>> there
>>>>> are
>>>>>>> any thoughts or objections to this approach.
>>>>>>>
>>>>>>> --
>>>>>>> Thanks,
>>>>>>> AG
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

[Alexey Goncharuk]

I like the idea of having PersistentMemoryPolicy configuration class.
Vladimir, Yakov, any objections?

2017-09-13 3:05 GMT+03:00 Denis Magda <[hidden email]>:

> I would go for PersistentMemoryPolicyConfiguration way if it will be
> expanded by storage related settings furthers.
>
> For instance, from the discussion on @user I see a raising demand for the
> storage maximum size. If it’s reached the data will be evicted from there
> too. Just as an example.
>
> —
> Denis
>
> > On Sep 12, 2017, at 2:01 PM, Dmitriy Setrakyan <[hidden email]>
> wrote:
> >
> > To extend on the idea of 2 different policies for memory and persistence,
> > can we have 2 completely different configuration classes?
> >
> > - MemoryPolicy
> > - PersistentMemoryPolicy (extends MemoryPolicy?)
> >
> > Every cache should be associated with either MemoryPolicy or
> > PersistentMemoryPolicy, but not both. By default, caches on startup are
> > associated with default MemoryPolicy. Users can always change it to some
> > PersistentMemoryPolicy, if persistence needs to be enabled.
> >
> > If we agree on the above, do we really need a persistenceEnabled flag at
> > all?
> >
> > D.
> >
> > On Tue, Sep 12, 2017 at 2:57 AM, Alexey Goncharuk <
> > [hidden email]> wrote:
> >
> >> We surely can, but:
> >> * we should then have two configuration settings for default memory
> policy
> >> size (one in-memory and one persisted)
> >> * a user still may configure multiple custom memory policies. In this
> >> case, the requirement to have this flag the same in a memory policy is
> >> still valid, so a user still can get exceptions.
> >>
> >> 2017-09-12 12:44 GMT+03:00 Vladimir Ozerov <[hidden email]>:
> >>
> >>> Alex,
> >>>
> >>> Can we have two default memory policies - one for in-memory and another
> >> one
> >>> for persistence cases?
> >>>
> >>> On Tue, Sep 12, 2017 at 12:40 PM, Alexey Goncharuk <
> >>> [hidden email]> wrote:
> >>>
> >>>> This is possible, but then if two caches belong to the same memory
> >>> policy,
> >>>> they must be both either persistence-enabled or persistence-disabled.
> >> We
> >>>> can add this validation, but I think this will lead to a greater
> >>> confusion
> >>>> for a user.
> >>>>
> >>>> 2017-09-12 12:34 GMT+03:00 Pavel Tupitsyn <[hidden email]>:
> >>>>
> >>>>> Agree with Vladimir.
> >>>>>
> >>>>> Currently we enable persistence cluster-wide by setting
> >>>>> IgniteConfiguration.persistentStoreConfiguration.
> >>>>> Ideally CacheConfiguration.persistenceEnabled should be the only
> >>>> setting I
> >>>>> need to set.
> >>>>>
> >>>>> Thanks,
> >>>>> Pavel
> >>>>>
> >>>>> On Tue, Sep 12, 2017 at 12:28 PM, Vladimir Ozerov <
> >>> [hidden email]>
> >>>>> wrote:
> >>>>>
> >>>>>> As a user I would definitely prefer to control persistence through
> >>> flag
> >>>>> on
> >>>>>> cache configuration. I do not even want to know what "memory
> >> policy"
> >>>> is.
> >>>>>> E.g. CacheConfiguration.persistenceEnabled.
> >>>>>>
> >>>>>> On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk <
> >>>>>> [hidden email]> wrote:
> >>>>>>
> >>>>>>> Igniters,
> >>>>>>>
> >>>>>>> I am currently reviewing a change allowing to enable persistence
> >>> on a
> >>>>>>> per-memory-policy basis (thanks to K. Dudkov!) and have a
> >> question
> >>>>>>> regarding the changes in configuration.
> >>>>>>>
> >>>>>>> The suggested change is to add a flag "persistenceEnabled"
> >>> (defaults
> >>>> to
> >>>>>>> true) to the memory policy configuration. To keep configuration
> >>>>>>> compatibility, the logic is as follows:
> >>>>>>>
> >>>>>>> If PersistentStoreConfiguration is set, then only memory policies
> >>>> with
> >>>>>>> persistenceEnabled=true flag will be persisted, which is
> >> consistent
> >>>>> with
> >>>>>>> the current behavior. To disable persistence, persistenceEnabled
> >>> flag
> >>>>>>> should be explicitly set to false.
> >>>>>>>
> >>>>>>> If PersistentStoreConfiguration is not set, then all caches are
> >>>> stored
> >>>>>>> in-memory and persistenceEnabled is ignored.
> >>>>>>>
> >>>>>>> While personally, I like this change, I would like to check if
> >>> there
> >>>>> are
> >>>>>>> any thoughts or objections to this approach.
> >>>>>>>
> >>>>>>> --
> >>>>>>> Thanks,
> >>>>>>> AG
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

[Vladimir Ozerov]

Sounds good. But can we see a full example of such configuration? E.g. we
have two caches, one in-memory, another persistent.

On Wed, Sep 13, 2017 at 10:54 AM, Alexey Goncharuk <
[hidden email]> wrote:

> I like the idea of having PersistentMemoryPolicy configuration class.
> Vladimir, Yakov, any objections?
>
> 2017-09-13 3:05 GMT+03:00 Denis Magda <[hidden email]>:
>
> > I would go for PersistentMemoryPolicyConfiguration way if it will be
> > expanded by storage related settings furthers.
> >
> > For instance, from the discussion on @user I see a raising demand for the
> > storage maximum size. If it’s reached the data will be evicted from there
> > too. Just as an example.
> >
> > —
> > Denis
> >
> > > On Sep 12, 2017, at 2:01 PM, Dmitriy Setrakyan <[hidden email]>
> > wrote:
> > >
> > > To extend on the idea of 2 different policies for memory and
> persistence,
> > > can we have 2 completely different configuration classes?
> > >
> > > - MemoryPolicy
> > > - PersistentMemoryPolicy (extends MemoryPolicy?)
> > >
> > > Every cache should be associated with either MemoryPolicy or
> > > PersistentMemoryPolicy, but not both. By default, caches on startup are
> > > associated with default MemoryPolicy. Users can always change it to
> some
> > > PersistentMemoryPolicy, if persistence needs to be enabled.
> > >
> > > If we agree on the above, do we really need a persistenceEnabled flag
> at
> > > all?
> > >
> > > D.
> > >
> > > On Tue, Sep 12, 2017 at 2:57 AM, Alexey Goncharuk <
> > > [hidden email]> wrote:
> > >
> > >> We surely can, but:
> > >> * we should then have two configuration settings for default memory
> > policy
> > >> size (one in-memory and one persisted)
> > >> * a user still may configure multiple custom memory policies. In this
> > >> case, the requirement to have this flag the same in a memory policy is
> > >> still valid, so a user still can get exceptions.
> > >>
> > >> 2017-09-12 12:44 GMT+03:00 Vladimir Ozerov <[hidden email]>:
> > >>
> > >>> Alex,
> > >>>
> > >>> Can we have two default memory policies - one for in-memory and
> another
> > >> one
> > >>> for persistence cases?
> > >>>
> > >>> On Tue, Sep 12, 2017 at 12:40 PM, Alexey Goncharuk <
> > >>> [hidden email]> wrote:
> > >>>
> > >>>> This is possible, but then if two caches belong to the same memory
> > >>> policy,
> > >>>> they must be both either persistence-enabled or
> persistence-disabled.
> > >> We
> > >>>> can add this validation, but I think this will lead to a greater
> > >>> confusion
> > >>>> for a user.
> > >>>>
> > >>>> 2017-09-12 12:34 GMT+03:00 Pavel Tupitsyn <[hidden email]>:
> > >>>>
> > >>>>> Agree with Vladimir.
> > >>>>>
> > >>>>> Currently we enable persistence cluster-wide by setting
> > >>>>> IgniteConfiguration.persistentStoreConfiguration.
> > >>>>> Ideally CacheConfiguration.persistenceEnabled should be the only
> > >>>> setting I
> > >>>>> need to set.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Pavel
> > >>>>>
> > >>>>> On Tue, Sep 12, 2017 at 12:28 PM, Vladimir Ozerov <
> > >>> [hidden email]>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> As a user I would definitely prefer to control persistence through
> > >>> flag
> > >>>>> on
> > >>>>>> cache configuration. I do not even want to know what "memory
> > >> policy"
> > >>>> is.
> > >>>>>> E.g. CacheConfiguration.persistenceEnabled.
> > >>>>>>
> > >>>>>> On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk <
> > >>>>>> [hidden email]> wrote:
> > >>>>>>
> > >>>>>>> Igniters,
> > >>>>>>>
> > >>>>>>> I am currently reviewing a change allowing to enable persistence
> > >>> on a
> > >>>>>>> per-memory-policy basis (thanks to K. Dudkov!) and have a
> > >> question
> > >>>>>>> regarding the changes in configuration.
> > >>>>>>>
> > >>>>>>> The suggested change is to add a flag "persistenceEnabled"
> > >>> (defaults
> > >>>> to
> > >>>>>>> true) to the memory policy configuration. To keep configuration
> > >>>>>>> compatibility, the logic is as follows:
> > >>>>>>>
> > >>>>>>> If PersistentStoreConfiguration is set, then only memory policies
> > >>>> with
> > >>>>>>> persistenceEnabled=true flag will be persisted, which is
> > >> consistent
> > >>>>> with
> > >>>>>>> the current behavior. To disable persistence, persistenceEnabled
> > >>> flag
> > >>>>>>> should be explicitly set to false.
> > >>>>>>>
> > >>>>>>> If PersistentStoreConfiguration is not set, then all caches are
> > >>>> stored
> > >>>>>>> in-memory and persistenceEnabled is ignored.
> > >>>>>>>
> > >>>>>>> While personally, I like this change, I would like to check if
> > >>> there
> > >>>>> are
> > >>>>>>> any thoughts or objections to this approach.
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Thanks,
> > >>>>>>> AG
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

[Константин Дудков]

Can we have separate MemoryPolycy for every CacheGroup? In that case we
could auto generate MemoryPolycy based on CacheGroup settings and have a
"cache level" persistence settings.

We can use some kind of MemoryPolicyTemplate to add default values and
even re-use existing MemoryPolicy if all settings are the same.

> To extend on the idea of 2 different policies for memory and persistence,
> can we have 2 completely different configuration classes?
>
>   - MemoryPolicy
>   - PersistentMemoryPolicy (extends MemoryPolicy?)
>
> Every cache should be associated with either MemoryPolicy or
> PersistentMemoryPolicy, but not both. By default, caches on startup are
> associated with default MemoryPolicy. Users can always change it to some
> PersistentMemoryPolicy, if persistence needs to be enabled.
>
> If we agree on the above, do we really need a persistenceEnabled flag at
> all?
>
> D.
>
> On Tue, Sep 12, 2017 at 2:57 AM, Alexey Goncharuk <
> [hidden email]> wrote:
>
>> We surely can, but:
>>   * we should then have two configuration settings for default memory policy
>> size (one in-memory and one persisted)
>>   * a user still may configure multiple custom memory policies. In this
>> case, the requirement to have this flag the same in a memory policy is
>> still valid, so a user still can get exceptions.
>>
>> 2017-09-12 12:44 GMT+03:00 Vladimir Ozerov <[hidden email]>:
>>
>>> Alex,
>>>
>>> Can we have two default memory policies - one for in-memory and another
>> one
>>> for persistence cases?
>>>
>>> On Tue, Sep 12, 2017 at 12:40 PM, Alexey Goncharuk <
>>> [hidden email]> wrote:
>>>
>>>> This is possible, but then if two caches belong to the same memory
>>> policy,
>>>> they must be both either persistence-enabled or persistence-disabled.
>> We
>>>> can add this validation, but I think this will lead to a greater
>>> confusion
>>>> for a user.
>>>>
>>>> 2017-09-12 12:34 GMT+03:00 Pavel Tupitsyn <[hidden email]>:
>>>>
>>>>> Agree with Vladimir.
>>>>>
>>>>> Currently we enable persistence cluster-wide by setting
>>>>> IgniteConfiguration.persistentStoreConfiguration.
>>>>> Ideally CacheConfiguration.persistenceEnabled should be the only
>>>> setting I
>>>>> need to set.
>>>>>
>>>>> Thanks,
>>>>> Pavel
>>>>>
>>>>> On Tue, Sep 12, 2017 at 12:28 PM, Vladimir Ozerov <
>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>>> As a user I would definitely prefer to control persistence through
>>> flag
>>>>> on
>>>>>> cache configuration. I do not even want to know what "memory
>> policy"
>>>> is.
>>>>>> E.g. CacheConfiguration.persistenceEnabled.
>>>>>>
>>>>>> On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>> Igniters,
>>>>>>>
>>>>>>> I am currently reviewing a change allowing to enable persistence
>>> on a
>>>>>>> per-memory-policy basis (thanks to K. Dudkov!) and have a
>> question
>>>>>>> regarding the changes in configuration.
>>>>>>>
>>>>>>> The suggested change is to add a flag "persistenceEnabled"
>>> (defaults
>>>> to
>>>>>>> true) to the memory policy configuration. To keep configuration
>>>>>>> compatibility, the logic is as follows:
>>>>>>>
>>>>>>> If PersistentStoreConfiguration is set, then only memory policies
>>>> with
>>>>>>> persistenceEnabled=true flag will be persisted, which is
>> consistent
>>>>> with
>>>>>>> the current behavior. To disable persistence, persistenceEnabled
>>> flag
>>>>>>> should be explicitly set to false.
>>>>>>>
>>>>>>> If PersistentStoreConfiguration is not set, then all caches are
>>>> stored
>>>>>>> in-memory and persistenceEnabled is ignored.
>>>>>>>
>>>>>>> While personally, I like this change, I would like to check if
>>> there
>>>>> are
>>>>>>> any thoughts or objections to this approach.
>>>>>>>
>>>>>>> --
>>>>>>> Thanks,
>>>>>>> AG
>>>>>>>

[yzhdanov]

> I like the idea of having PersistentMemoryPolicy configuration class.

I like the idea, too.

--Yakov

[yzhdanov]

>>Can we have separate MemoryPolycy for every CacheGroup? In that case we
could auto generate MemoryPolycy based on CacheGroup settings and have a
"cache level" persistence settings.
>>We can use some kind of MemoryPolicyTemplate to add default values and
even re-use existing MemoryPolicy if all settings are the same.

Konstantin, can you please elaborate?

--Yakov

[Alexey Goncharuk]

Vladimir,

The configuration would look like so:

IgniteConfiguration cfg = new IgniteConfiguration();

cfg.setMemoryConfiguration(new MemoryConfiguration()
    .setMemoryPolicies(
        new MemoryPolicyConfiguration().setName("InMemory").setMaxSize(...),
        new PersistentMemoryPolicyConfiguration().setName("Persisted").setMaxSize(...));

cfg.setCacheConfiguration(
    new CacheConfiguration("tmpCache").setMemoryPolicyName("InMemory"),
    new CacheConfiguration("dbCache").setMemoryPolicyName("Persisted"));



2017-09-14 12:20 GMT+03:00 Yakov Zhdanov <[hidden email]>:

> >>Can we have separate MemoryPolycy for every CacheGroup? In that case we
> could auto generate MemoryPolycy based on CacheGroup settings and have a
> "cache level" persistence settings.
> >>We can use some kind of MemoryPolicyTemplate to add default values and
> even re-use existing MemoryPolicy if all settings are the same.
>
> Konstantin, can you please elaborate?
>
> --Yakov
>

[Alexey Goncharuk]

Reiterating this based on some feedback from PDS users.

It might be confusing to configure persistence with "MemoryPolicy", so
another approach is to deprecate the old names and introduce a new name
"DataRegion" because it reflects the actual state when data is stored on
disk and partially in memory. I have two options in mind, each of them
looks acceptable to me, so I would like to have some feedback from the
community. Old configuration names will be deprecated (but still be taken
if used for backward compatibility). Note, that old names deprecation
handles default configuration compatibility very nicely - current PDS users
will not need to change anything to keep everything working. The two
options I mentioned are below:

 * we have two separate classes for in-memory and persisted data regions,
so the configuration would look like so:

IgniteConfiguration cfg = new IgniteConfiguration();

cfg.setDataRegionsConfiguration(new DataRegionsConfiguration()
    .setDataRegions(
        new MemoryDataRegion()
            .setName("volatileCaches")
            .setMaxMemorySize(...),
        new PersistentDataRegion()
            .setName("persistentCaches")
            .setMaxMemorySize(...)
            .setMaxDiskSize()));

cfg.setPersistentStoreConfiguration(new PersistentStoreConfiguration());


* we have one class for data region configuration, but it will have a
sub-bean for persistence configuration:

IgniteConfiguration cfg = new IgniteConfiguration();

cfg.setDataRegionsConfiguration(new DataRegionsConfiguration()
    .setDataRegions(
        new DataRegion()
            .setName("volatileCaches")
            .setMaxMemorySize(...),
        new DataRegion()
            .setName("persistentCaches")
            .setMaxMemorySize(...),
            .setPersistenceConfiguration(
                new DataRegionPersistenceConfiguration()
                    .setMaxDiskSize(...))));

cfg.setPersistentStoreConfiguration(new PersistentStoreConfiguration());