Persistence per memory policy configuration

classic Classic list List threaded Threaded
94 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

dmagda
Vote for 1.


Denis

> On Sep 26, 2017, at 11:23 PM, Vladimir Ozerov <[hidden email]> wrote:
>
> Folks,
>
> Let me summarize current naming ideas one more time:
>
> 1) [StorageConfiguration - StorageRegionConfiguration]
> 2) [DurableMemoryConfiguration - DataRegionConfiguration]
> 3) [DurableMemoryConfiguration - DurableMemoryRegionConfiguration] - out of
> question, as "durable memory region" is too misleading.
>
> My vote for p.1. Short, simple and intuitive.
>
> Vladimir.
>
> On Tue, Sep 26, 2017 at 10:16 PM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
>> On Tue, Sep 26, 2017 at 7:33 AM, Dmitry Pavlov <[hidden email]>
>> wrote:
>>
>>> Hi Dmitriy, thank you for reply. Do you agree Memory Policy already
>> became
>>> Ignite's term? We call this configuration now
>> MemoryPolicy(Configuration),
>>> can we call new configuration elments by their existings name? We can
>> avoid
>>> introduction of second Ignite's term in that case.
>>>
>>
>> The refactoring is about merging memory and persistence configuration under
>> the same umbrella. The term "MemoryPolicy" does not make sense anymore,
>> given that it now also includes persistent configuration as well.
>>
>>
>>>
>>> вт, 26 сент. 2017 г. в 17:27, Dmitriy Setrakyan <[hidden email]>:
>>>
>>>> Dmitriy, we are not renaming classes, we are refactoring them. Prior to
>>>> this design, it was impossible to set persistence configuration on
>>>> per-cache basis. With this new design, users will be able to configure
>>> some
>>>> caches to be in-memory only and others to be on disk.
>>>>
>>>> Given that we are already refactoring, it only makes sense to pick
>>> better,
>>>> more appropriate names.
>>>>
>>>> D.
>>>>
>>>> On Tue, Sep 26, 2017 at 7:20 AM, Dmitry Pavlov <[hidden email]>
>>>> wrote:
>>>>
>>>>> Vladimir, it is not clear for me, why we need to rename existing
>>>>> configuration classes. Could you explain? And if we can't get
>> consensus
>>>>> now, should we pospond solution?
>>>>>
>>>>> My idea is that user needs this feature more than elegant names in
>>>>> configuration.
>>>>>
>>>>> Moreover once MemoryPolicyConfiguration was introduced as Ignite term
>>> it
>>>> is
>>>>> simpler to keep it as is, than create new terms.
>>>>>
>>>>> Sincerely,
>>>>> Dmitriy Pavlov
>>>>>
>>>>> вт, 26 сент. 2017 г. в 16:59, Vladimir Ozerov <[hidden email]
>>> :
>>>>>
>>>>>> I do not understand why we should delay with renames. Yes, it will
>>>> cause
>>>>>> questions, so we will have to put additional efforts to docs and
>>>>> JavaDocs.
>>>>>> But the earlier we do that, the better.
>>>>>>
>>>>>> On Tue, Sep 26, 2017 at 4:50 PM, Dmitry Pavlov <
>>> [hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Igniters, sorry for late response. I didn't catch idea of
>>>> renaming.
>>>>>>> PersistentStoreConfiguration is intuitive, and
>>>>> MemoryPolicyConfiguration
>>>>>> is
>>>>>>> intuitive also.
>>>>>>>
>>>>>>> If we rename these classes now, it will bring more questions to
>>> user
>>>>>> list.
>>>>>>> Users may be confused by old and new names and by trying to match
>>> it.
>>>>>> More
>>>>>>> issues can came from XML configs that users already have.
>>>>>>>
>>>>>>> Can we postpone the renaming? I suggest to finish 'persistence
>> per
>>>>> memory
>>>>>>> policy' task without renaming, and create separate JIRA issue for
>>>>>> creating
>>>>>>> future decision?
>>>>>>>
>>>>>>> вт, 26 сент. 2017 г. в 15:25, Alexey Goncharuk <
>>>>>> [hidden email]
>>>>>>>> :
>>>>>>>
>>>>>>>> I do not like DurableMemoryConfiguration, because it's quite
>>>>> confusing
>>>>>> -
>>>>>>> we
>>>>>>>> configure in-memory caches using DurableMemory class, which
>>>>> immediately
>>>>>>>> suggests that everything will be persisted. I am not sure if
>> this
>>>> is
>>>>> a
>>>>>>>> right wording choice for the documentation either. I would go
>>> with
>>>>>>>> DataStoreConfiguration and DataRegionConfiguration.
>>>>>>>>
>>>>>>>> --AG
>>>>>>>>
>>>>>>>> 2017-09-26 2:22 GMT+03:00 Dmitriy Setrakyan <
>>> [hidden email]
>>>>> :
>>>>>>>>
>>>>>>>>> Given that we already have a notion of CacheStore which comes
>>>> from
>>>>>>> JCache
>>>>>>>>> spec, I think having other stores may get confusing. I like
>>>>>>>>> DurableMemoryConfiguration.
>>>>>>>>>
>>>>>>>>> Other opinions?
>>>>>>>>>
>>>>>>>>> D.
>>>>>>>>>
>>>>>>>>> On Mon, Sep 25, 2017 at 12:24 PM, Vladimir Ozerov <
>>>>>>> [hidden email]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Dima, let's finalize the design first.
>>>>>>>>>>
>>>>>>>>>> As I understand, we are happy with idea to merge
>>>>>> MemoryConfiguration
>>>>>>>>>> and PersistentStoreConfiguration
>>>>>>>>>> into something what I called DataConfiguration, and to
>> rename
>>>>>>>>>> MemoryPolicyConfiguration to DataRegionConfiguration.
>>>>>>>>>>
>>>>>>>>>> The only outstanding qurestion is whether DataConfiguration
>>> is
>>>> a
>>>>>> good
>>>>>>>>> name.
>>>>>>>>>> I am not very happy with it, so let's think of other
>>>>> alternatives.
>>>>>>>> Quick
>>>>>>>>>> ideas:
>>>>>>>>>> 1) StoreConfiguration - looks perfect to me - short and
>>>>>>>> self-describing,
>>>>>>>>>> but clashes a bit with existing CacheStore
>>>>>>>>>> 2) DataStoreConfiguration - same as p.1, but the word
>> "data"
>>> is
>>>>> not
>>>>>>>>>> necessary IMO
>>>>>>>>>> 3) PageStoreConfiguration? GIves a hint to our page-based
>>>>>>> architecture.
>>>>>>>>>> 4) DurableMemoryConfiguration - aligns well with our docs,
>>> but
>>>> I
>>>>> do
>>>>>>> not
>>>>>>>>>> like it - too long and misleading
>>>>>>>>>>
>>>>>>>>>> Any other ideas?
>>>>>>>>>>
>>>>>>>>>> I would prefer to have either [StoreConfiguration +
>>>>>>>>>> StoreRegionConfiguration] or [PageStoreConfiguration and
>>>>>>>>>> PageStoreRegionConfiguration]. Looks clean and simple.
>>>>>>>>>>
>>>>>>>>>> Vladimir.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Sep 25, 2017 at 3:49 PM, Dmitriy Setrakyan <
>>>>>>>>> [hidden email]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Vladimir,
>>>>>>>>>>>
>>>>>>>>>>> Can you please add the configuration example in the
>> ticket?
>>>>>>>>>>>
>>>>>>>>>>> D.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Sep 25, 2017 at 12:20 AM, Alexey Goncharuk <
>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Guys,
>>>>>>>>>>>>
>>>>>>>>>>>> I suggest we finalize the configuration changes in the
>>>>> original
>>>>>>>>> ticket
>>>>>>>>>>>> then: https://issues.apache.org/
>> jira/browse/IGNITE-6030
>>>> and
>>>>>>>> proceed
>>>>>>>>>> with
>>>>>>>>>>>> the changes.
>>>>>>>>>>>>
>>>>>>>>>>>> 2017-09-23 17:08 GMT+03:00 Dmitriy Setrakyan <
>>>>>>>> [hidden email]
>>>>>>>>>> :
>>>>>>>>>>>>
>>>>>>>>>>>>> Can we specify what metrics will look like? I think
>> we
>>>>> should
>>>>>>> not
>>>>>>>>>> just
>>>>>>>>>>>>> blindly merge them.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Sep 22, 2017 at 11:01 PM, Vladimir Ozerov <
>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Denis,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Makes sense. Thanks for catching it!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sat, Sep 23, 2017 at 8:45 AM, Denis Magda <
>>>>>>>> [hidden email]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If we’re taking the consolidation path for Memory
>>> and
>>>>>>>>> Persistence
>>>>>>>>>>>>>>> configurations then it makes sense to merge
>>>>> MemoryMetrics
>>>>>>> [1]
>>>>>>>>> and
>>>>>>>>>>>>>>> PersistenceMetrics [2] plus their JMX beans.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Agree?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1]
>>>>>> https://ignite.apache.org/releases/latest/javadoc/org/
>>>>>>>>>>>>>>> apache/ignite/MemoryMetrics.html <
>>>>>>> https://ignite.apache.org/
>>>>>>>>>>>>>>> releases/latest/javadoc/org/
>>>>> apache/ignite/MemoryMetrics.
>>>>>>> html>
>>>>>>>>>>>>>>> [2]
>>>>>> https://ignite.apache.org/releases/latest/javadoc/org/
>>>>>>>>>>>>> apache/ignite/
>>>>>>>>>>>>>>> PersistenceMetrics.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> —
>>>>>>>>>>>>>>> Denis
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sep 22, 2017, at 10:18 PM, Dmitriy
>> Setrakyan <
>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I like it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Alexey G, can you please chime in?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> D.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Sep 22, 2017 at 11:33 AM, Vladimir
>>> Ozerov <
>>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Guys,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Here is my proposal:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1) MemoryPolicyConfiguration is renamed to
>>>>>>>>>>>>> *DataRegionConfiguration*.
>>>>>>>>>>>>>>>>> 2) PersistenceConfiguration is merged with
>>>>>>>>> MemoryConfiguration
>>>>>>>>>>> and
>>>>>>>>>>>>>>> renamed
>>>>>>>>>>>>>>>>> to ... *DataStorageConfiguration*! It has:
>>> common
>>>>>> memory
>>>>>>>>>>> settings
>>>>>>>>>>>>>> (e.g.
>>>>>>>>>>>>>>>>> default data region), persistence settings
>> (e.g.
>>>>> WAL)
>>>>>>> and
>>>>>>>> a
>>>>>>>>>> list
>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> DataRegionConfiguration beans.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What we have in the end:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <property name="dataConfiguration">
>>>>>>>>>>>>>>>>>   <bean class="o.a.i.DataConfiguration">
>>>>>>>>>>>>>>>>>       <property name="pageSize" value="8192"
>> />
>>>>>>>>>>>>>>>>>       <property name="persistentStorePath"
>>>>>>>> value="/my/path"
>>>>>>>>>> />
>>>>>>>>>>>>>>>>>       <property name="dataRegions">
>>>>>>>>>>>>>>>>>           <list>
>>>>>>>>>>>>>>>>>               <bean
>>>>>>>> class="o.a.i.DataRegionConfiguration">
>>>>>>>>>>>>>>>>>                   <property name="name"
>>>>>>> value="VOLATILE"
>>>>>>>> />
>>>>>>>>>>>>>>>>>                   <property name="maxSize"
>>>>>>>>>>> value="1_000_000_000"
>>>>>>>>>>>> />
>>>>>>>>>>>>>>>>>               </bean>
>>>>>>>>>>>>>>>>>               <bean
>>>>>>>> class="o.a.i.DataRegionConfiguration">
>>>>>>>>>>>>>>>>>                   <property name="name"
>>>>>>>> value="PERSISTENT"
>>>>>>>>> />
>>>>>>>>>>>>>>>>>                   <property name="maxSize"
>>>>>>>>>>> value="1_000_000_000"
>>>>>>>>>>>> />
>>>>>>>>>>>>>>>>>                   <property name="persistent"
>>>>>>>> value="true"
>>>>>>>>> />
>>>>>>>>>>>>>>>>>               </bean>
>>>>>>>>>>>>>>>>>           </list>
>>>>>>>>>>>>>>>>>       </property>
>>>>>>>>>>>>>>>>>   </bean>
>>>>>>>>>>>>>>>>> </property>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Makes sense?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Vladimir.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Sep 21, 2017 at 7:04 AM, Dmitriy
>>>> Setrakyan <
>>>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Firstly all, why not call it DataPolicy
>> instead
>>>> of
>>>>>>>>>>> MemoryPolicy?
>>>>>>>>>>>>>>>>> Secondly,
>>>>>>>>>>>>>>>>>> why not set data policies directly on
>>>>>>>> IgniteConfiguration.
>>>>>>>>>> And
>>>>>>>>>>>>>> lastly,
>>>>>>>>>>>>>>>>> how
>>>>>>>>>>>>>>>>>> about we combine memory and disk properties
>> in
>>>> one
>>>>>> bean
>>>>>>>>> with
>>>>>>>>>>>> clear
>>>>>>>>>>>>>>> naming
>>>>>>>>>>>>>>>>>> convention?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Here is the example. Note that all properties
>>>> above
>>>>>>> must
>>>>>>>>>> start
>>>>>>>>>>>> with
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>> "Memory" or "Disk".
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *IgniteConfiguration cfg = new
>>>>>> IgniteConfiguration();*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *cfg.setDataPolicies(    new
>>>>>> DataPolicyConfiguration()
>>>>>>>>>>>>>>>>>>> .setName("bla"),
>>> .setMemoryMaxSize(1024),
>>>>> //
>>>>>>> must
>>>>>>>>> be
>>>>>>>>>>>>> greater
>>>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>>> 0,
>>>>>>>>>>>>>>>>>>> since memory always needs to be enabled.
>>>>>>>>>>>>> .setDiskMaxSize(0),
>>>>>>>>>>>>>> //
>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>> greater than 0, then persistence is enabled.
>>>>> );*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think this approach is much more concise
>> and
>>>>>> straight
>>>>>>>>>>> forward.
>>>>>>>>>>>>> What
>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>> you think?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> D.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Wed, Sep 20, 2017 at 4:55 AM, Vladimir
>>> Ozerov
>>>> <
>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I prefer the second. Composition over
>>>> inheritance
>>>>> -
>>>>>>> this
>>>>>>>>> is
>>>>>>>>>>> how
>>>>>>>>>>>>> all
>>>>>>>>>>>>>>> our
>>>>>>>>>>>>>>>>>>> configuration is crafted.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> E.g. we do not have "CacheConfiguration"
>> and "
>>>>>>>>>>>>>>>>>>> StoreEnabledCacheConfiguration".
>>>>>>>>>>>>>>>>>>> Instead, we have "CacheConfiguration.
>>>>>>>>> setCacheStoreFactory".
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Wed, Sep 20, 2017 at 2:46 PM, Alexey
>>>> Goncharuk
>>>>> <
>>>>>>>>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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
>>>> DataRegionPersistenceConfigura
>>>>>>> tion()
>>>>>>>>>>>>>>>>>>>>                   .setMaxDiskSize(...))));
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> cfg.setPersistentStoreConfiguration(new
>>>>>>>>>>>>>>>>> PersistentStoreConfiguration()
>>>>>>>>>>>>>>>>>> );
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

Alexey Goncharuk
My vote also goes for 1. I guess it is safe to assume that at this point we
came to a consensus?

2017-09-27 21:52 GMT+03:00 Denis Magda <[hidden email]>:

> Vote for 1.
>
> —
> Denis
>
> > On Sep 26, 2017, at 11:23 PM, Vladimir Ozerov <[hidden email]>
> wrote:
> >
> > Folks,
> >
> > Let me summarize current naming ideas one more time:
> >
> > 1) [StorageConfiguration - StorageRegionConfiguration]
> > 2) [DurableMemoryConfiguration - DataRegionConfiguration]
> > 3) [DurableMemoryConfiguration - DurableMemoryRegionConfiguration] -
> out of
> > question, as "durable memory region" is too misleading.
> >
> > My vote for p.1. Short, simple and intuitive.
> >
> > Vladimir.
> >
> > On Tue, Sep 26, 2017 at 10:16 PM, Dmitriy Setrakyan <
> [hidden email]>
> > wrote:
> >
> >> On Tue, Sep 26, 2017 at 7:33 AM, Dmitry Pavlov <[hidden email]>
> >> wrote:
> >>
> >>> Hi Dmitriy, thank you for reply. Do you agree Memory Policy already
> >> became
> >>> Ignite's term? We call this configuration now
> >> MemoryPolicy(Configuration),
> >>> can we call new configuration elments by their existings name? We can
> >> avoid
> >>> introduction of second Ignite's term in that case.
> >>>
> >>
> >> The refactoring is about merging memory and persistence configuration
> under
> >> the same umbrella. The term "MemoryPolicy" does not make sense anymore,
> >> given that it now also includes persistent configuration as well.
> >>
> >>
> >>>
> >>> вт, 26 сент. 2017 г. в 17:27, Dmitriy Setrakyan <[hidden email]
> >:
> >>>
> >>>> Dmitriy, we are not renaming classes, we are refactoring them. Prior
> to
> >>>> this design, it was impossible to set persistence configuration on
> >>>> per-cache basis. With this new design, users will be able to configure
> >>> some
> >>>> caches to be in-memory only and others to be on disk.
> >>>>
> >>>> Given that we are already refactoring, it only makes sense to pick
> >>> better,
> >>>> more appropriate names.
> >>>>
> >>>> D.
> >>>>
> >>>> On Tue, Sep 26, 2017 at 7:20 AM, Dmitry Pavlov <[hidden email]
> >
> >>>> wrote:
> >>>>
> >>>>> Vladimir, it is not clear for me, why we need to rename existing
> >>>>> configuration classes. Could you explain? And if we can't get
> >> consensus
> >>>>> now, should we pospond solution?
> >>>>>
> >>>>> My idea is that user needs this feature more than elegant names in
> >>>>> configuration.
> >>>>>
> >>>>> Moreover once MemoryPolicyConfiguration was introduced as Ignite term
> >>> it
> >>>> is
> >>>>> simpler to keep it as is, than create new terms.
> >>>>>
> >>>>> Sincerely,
> >>>>> Dmitriy Pavlov
> >>>>>
> >>>>> вт, 26 сент. 2017 г. в 16:59, Vladimir Ozerov <[hidden email]
> >>> :
> >>>>>
> >>>>>> I do not understand why we should delay with renames. Yes, it will
> >>>> cause
> >>>>>> questions, so we will have to put additional efforts to docs and
> >>>>> JavaDocs.
> >>>>>> But the earlier we do that, the better.
> >>>>>>
> >>>>>> On Tue, Sep 26, 2017 at 4:50 PM, Dmitry Pavlov <
> >>> [hidden email]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi Igniters, sorry for late response. I didn't catch idea of
> >>>> renaming.
> >>>>>>> PersistentStoreConfiguration is intuitive, and
> >>>>> MemoryPolicyConfiguration
> >>>>>> is
> >>>>>>> intuitive also.
> >>>>>>>
> >>>>>>> If we rename these classes now, it will bring more questions to
> >>> user
> >>>>>> list.
> >>>>>>> Users may be confused by old and new names and by trying to match
> >>> it.
> >>>>>> More
> >>>>>>> issues can came from XML configs that users already have.
> >>>>>>>
> >>>>>>> Can we postpone the renaming? I suggest to finish 'persistence
> >> per
> >>>>> memory
> >>>>>>> policy' task without renaming, and create separate JIRA issue for
> >>>>>> creating
> >>>>>>> future decision?
> >>>>>>>
> >>>>>>> вт, 26 сент. 2017 г. в 15:25, Alexey Goncharuk <
> >>>>>> [hidden email]
> >>>>>>>> :
> >>>>>>>
> >>>>>>>> I do not like DurableMemoryConfiguration, because it's quite
> >>>>> confusing
> >>>>>> -
> >>>>>>> we
> >>>>>>>> configure in-memory caches using DurableMemory class, which
> >>>>> immediately
> >>>>>>>> suggests that everything will be persisted. I am not sure if
> >> this
> >>>> is
> >>>>> a
> >>>>>>>> right wording choice for the documentation either. I would go
> >>> with
> >>>>>>>> DataStoreConfiguration and DataRegionConfiguration.
> >>>>>>>>
> >>>>>>>> --AG
> >>>>>>>>
> >>>>>>>> 2017-09-26 2:22 GMT+03:00 Dmitriy Setrakyan <
> >>> [hidden email]
> >>>>> :
> >>>>>>>>
> >>>>>>>>> Given that we already have a notion of CacheStore which comes
> >>>> from
> >>>>>>> JCache
> >>>>>>>>> spec, I think having other stores may get confusing. I like
> >>>>>>>>> DurableMemoryConfiguration.
> >>>>>>>>>
> >>>>>>>>> Other opinions?
> >>>>>>>>>
> >>>>>>>>> D.
> >>>>>>>>>
> >>>>>>>>> On Mon, Sep 25, 2017 at 12:24 PM, Vladimir Ozerov <
> >>>>>>> [hidden email]>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Dima, let's finalize the design first.
> >>>>>>>>>>
> >>>>>>>>>> As I understand, we are happy with idea to merge
> >>>>>> MemoryConfiguration
> >>>>>>>>>> and PersistentStoreConfiguration
> >>>>>>>>>> into something what I called DataConfiguration, and to
> >> rename
> >>>>>>>>>> MemoryPolicyConfiguration to DataRegionConfiguration.
> >>>>>>>>>>
> >>>>>>>>>> The only outstanding qurestion is whether DataConfiguration
> >>> is
> >>>> a
> >>>>>> good
> >>>>>>>>> name.
> >>>>>>>>>> I am not very happy with it, so let's think of other
> >>>>> alternatives.
> >>>>>>>> Quick
> >>>>>>>>>> ideas:
> >>>>>>>>>> 1) StoreConfiguration - looks perfect to me - short and
> >>>>>>>> self-describing,
> >>>>>>>>>> but clashes a bit with existing CacheStore
> >>>>>>>>>> 2) DataStoreConfiguration - same as p.1, but the word
> >> "data"
> >>> is
> >>>>> not
> >>>>>>>>>> necessary IMO
> >>>>>>>>>> 3) PageStoreConfiguration? GIves a hint to our page-based
> >>>>>>> architecture.
> >>>>>>>>>> 4) DurableMemoryConfiguration - aligns well with our docs,
> >>> but
> >>>> I
> >>>>> do
> >>>>>>> not
> >>>>>>>>>> like it - too long and misleading
> >>>>>>>>>>
> >>>>>>>>>> Any other ideas?
> >>>>>>>>>>
> >>>>>>>>>> I would prefer to have either [StoreConfiguration +
> >>>>>>>>>> StoreRegionConfiguration] or [PageStoreConfiguration and
> >>>>>>>>>> PageStoreRegionConfiguration]. Looks clean and simple.
> >>>>>>>>>>
> >>>>>>>>>> Vladimir.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Sep 25, 2017 at 3:49 PM, Dmitriy Setrakyan <
> >>>>>>>>> [hidden email]>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Vladimir,
> >>>>>>>>>>>
> >>>>>>>>>>> Can you please add the configuration example in the
> >> ticket?
> >>>>>>>>>>>
> >>>>>>>>>>> D.
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, Sep 25, 2017 at 12:20 AM, Alexey Goncharuk <
> >>>>>>>>>>> [hidden email]> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Guys,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I suggest we finalize the configuration changes in the
> >>>>> original
> >>>>>>>>> ticket
> >>>>>>>>>>>> then: https://issues.apache.org/
> >> jira/browse/IGNITE-6030
> >>>> and
> >>>>>>>> proceed
> >>>>>>>>>> with
> >>>>>>>>>>>> the changes.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2017-09-23 17:08 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>> [hidden email]
> >>>>>>>>>> :
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Can we specify what metrics will look like? I think
> >> we
> >>>>> should
> >>>>>>> not
> >>>>>>>>>> just
> >>>>>>>>>>>>> blindly merge them.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Fri, Sep 22, 2017 at 11:01 PM, Vladimir Ozerov <
> >>>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Denis,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Makes sense. Thanks for catching it!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Sat, Sep 23, 2017 at 8:45 AM, Denis Magda <
> >>>>>>>> [hidden email]>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If we’re taking the consolidation path for Memory
> >>> and
> >>>>>>>>> Persistence
> >>>>>>>>>>>>>>> configurations then it makes sense to merge
> >>>>> MemoryMetrics
> >>>>>>> [1]
> >>>>>>>>> and
> >>>>>>>>>>>>>>> PersistenceMetrics [2] plus their JMX beans.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Agree?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> [1]
> >>>>>> https://ignite.apache.org/releases/latest/javadoc/org/
> >>>>>>>>>>>>>>> apache/ignite/MemoryMetrics.html <
> >>>>>>> https://ignite.apache.org/
> >>>>>>>>>>>>>>> releases/latest/javadoc/org/
> >>>>> apache/ignite/MemoryMetrics.
> >>>>>>> html>
> >>>>>>>>>>>>>>> [2]
> >>>>>> https://ignite.apache.org/releases/latest/javadoc/org/
> >>>>>>>>>>>>> apache/ignite/
> >>>>>>>>>>>>>>> PersistenceMetrics.html
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> —
> >>>>>>>>>>>>>>> Denis
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Sep 22, 2017, at 10:18 PM, Dmitriy
> >> Setrakyan <
> >>>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I like it.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Alexey G, can you please chime in?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> D.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Fri, Sep 22, 2017 at 11:33 AM, Vladimir
> >>> Ozerov <
> >>>>>>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Guys,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Here is my proposal:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 1) MemoryPolicyConfiguration is renamed to
> >>>>>>>>>>>>> *DataRegionConfiguration*.
> >>>>>>>>>>>>>>>>> 2) PersistenceConfiguration is merged with
> >>>>>>>>> MemoryConfiguration
> >>>>>>>>>>> and
> >>>>>>>>>>>>>>> renamed
> >>>>>>>>>>>>>>>>> to ... *DataStorageConfiguration*! It has:
> >>> common
> >>>>>> memory
> >>>>>>>>>>> settings
> >>>>>>>>>>>>>> (e.g.
> >>>>>>>>>>>>>>>>> default data region), persistence settings
> >> (e.g.
> >>>>> WAL)
> >>>>>>> and
> >>>>>>>> a
> >>>>>>>>>> list
> >>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>> DataRegionConfiguration beans.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> What we have in the end:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> <property name="dataConfiguration">
> >>>>>>>>>>>>>>>>>   <bean class="o.a.i.DataConfiguration">
> >>>>>>>>>>>>>>>>>       <property name="pageSize" value="8192"
> >> />
> >>>>>>>>>>>>>>>>>       <property name="persistentStorePath"
> >>>>>>>> value="/my/path"
> >>>>>>>>>> />
> >>>>>>>>>>>>>>>>>       <property name="dataRegions">
> >>>>>>>>>>>>>>>>>           <list>
> >>>>>>>>>>>>>>>>>               <bean
> >>>>>>>> class="o.a.i.DataRegionConfiguration">
> >>>>>>>>>>>>>>>>>                   <property name="name"
> >>>>>>> value="VOLATILE"
> >>>>>>>> />
> >>>>>>>>>>>>>>>>>                   <property name="maxSize"
> >>>>>>>>>>> value="1_000_000_000"
> >>>>>>>>>>>> />
> >>>>>>>>>>>>>>>>>               </bean>
> >>>>>>>>>>>>>>>>>               <bean
> >>>>>>>> class="o.a.i.DataRegionConfiguration">
> >>>>>>>>>>>>>>>>>                   <property name="name"
> >>>>>>>> value="PERSISTENT"
> >>>>>>>>> />
> >>>>>>>>>>>>>>>>>                   <property name="maxSize"
> >>>>>>>>>>> value="1_000_000_000"
> >>>>>>>>>>>> />
> >>>>>>>>>>>>>>>>>                   <property name="persistent"
> >>>>>>>> value="true"
> >>>>>>>>> />
> >>>>>>>>>>>>>>>>>               </bean>
> >>>>>>>>>>>>>>>>>           </list>
> >>>>>>>>>>>>>>>>>       </property>
> >>>>>>>>>>>>>>>>>   </bean>
> >>>>>>>>>>>>>>>>> </property>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Makes sense?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Vladimir.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Thu, Sep 21, 2017 at 7:04 AM, Dmitriy
> >>>> Setrakyan <
> >>>>>>>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Firstly all, why not call it DataPolicy
> >> instead
> >>>> of
> >>>>>>>>>>> MemoryPolicy?
> >>>>>>>>>>>>>>>>> Secondly,
> >>>>>>>>>>>>>>>>>> why not set data policies directly on
> >>>>>>>> IgniteConfiguration.
> >>>>>>>>>> And
> >>>>>>>>>>>>>> lastly,
> >>>>>>>>>>>>>>>>> how
> >>>>>>>>>>>>>>>>>> about we combine memory and disk properties
> >> in
> >>>> one
> >>>>>> bean
> >>>>>>>>> with
> >>>>>>>>>>>> clear
> >>>>>>>>>>>>>>> naming
> >>>>>>>>>>>>>>>>>> convention?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Here is the example. Note that all properties
> >>>> above
> >>>>>>> must
> >>>>>>>>>> start
> >>>>>>>>>>>> with
> >>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>> "Memory" or "Disk".
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *IgniteConfiguration cfg = new
> >>>>>> IgniteConfiguration();*
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> *cfg.setDataPolicies(    new
> >>>>>> DataPolicyConfiguration()
> >>>>>>>>>>>>>>>>>>> .setName("bla"),
> >>> .setMemoryMaxSize(1024),
> >>>>> //
> >>>>>>> must
> >>>>>>>>> be
> >>>>>>>>>>>>> greater
> >>>>>>>>>>>>>>>>> than
> >>>>>>>>>>>>>>>>>> 0,
> >>>>>>>>>>>>>>>>>>> since memory always needs to be enabled.
> >>>>>>>>>>>>> .setDiskMaxSize(0),
> >>>>>>>>>>>>>> //
> >>>>>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>>>> greater than 0, then persistence is enabled.
> >>>>> );*
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I think this approach is much more concise
> >> and
> >>>>>> straight
> >>>>>>>>>>> forward.
> >>>>>>>>>>>>> What
> >>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>>>> you think?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> D.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Wed, Sep 20, 2017 at 4:55 AM, Vladimir
> >>> Ozerov
> >>>> <
> >>>>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I prefer the second. Composition over
> >>>> inheritance
> >>>>> -
> >>>>>>> this
> >>>>>>>>> is
> >>>>>>>>>>> how
> >>>>>>>>>>>>> all
> >>>>>>>>>>>>>>> our
> >>>>>>>>>>>>>>>>>>> configuration is crafted.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> E.g. we do not have "CacheConfiguration"
> >> and "
> >>>>>>>>>>>>>>>>>>> StoreEnabledCacheConfiguration".
> >>>>>>>>>>>>>>>>>>> Instead, we have "CacheConfiguration.
> >>>>>>>>> setCacheStoreFactory".
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Wed, Sep 20, 2017 at 2:46 PM, Alexey
> >>>> Goncharuk
> >>>>> <
> >>>>>>>>>>>>>>>>>>> [hidden email]> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 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
> >>>> DataRegionPersistenceConfigura
> >>>>>>> tion()
> >>>>>>>>>>>>>>>>>>>>                   .setMaxDiskSize(...))));
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> cfg.setPersistentStoreConfiguration(new
> >>>>>>>>>>>>>>>>> PersistentStoreConfiguration()
> >>>>>>>>>>>>>>>>>> );
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

yzhdanov
> I guess it is safe to assume that at this point we came to a consensus?

Alex, I think so. Let's carve it in stone (code).

--Yakov
Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

Vladimir Ozerov
Guys,

But what is exact desicion? :-) I saw two final options:

1) StorageConfiguration + StorageRegionConfiguration
2) DataStorageConfiguration + DataRegionConfiguration

Which one we choose?

On Thu, Sep 28, 2017 at 5:10 PM, Yakov Zhdanov <[hidden email]> wrote:

> > I guess it is safe to assume that at this point we came to a consensus?
>
> Alex, I think so. Let's carve it in stone (code).
>
> --Yakov
>
Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

yzhdanov
StorageConfiguration + StorageRegionConfiguration

--Yakov
Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

dsetrakyan
In reply to this post by Vladimir Ozerov
StorageRegion sounds like bad English to me.

I would go with DataStorageConfiguration and DataRegionConfiguration.

D.

On Thu, Sep 28, 2017 at 7:24 AM, Vladimir Ozerov <[hidden email]>
wrote:

> Guys,
>
> But what is exact desicion? :-) I saw two final options:
>
> 1) StorageConfiguration + StorageRegionConfiguration
> 2) DataStorageConfiguration + DataRegionConfiguration
>
> Which one we choose?
>
> On Thu, Sep 28, 2017 at 5:10 PM, Yakov Zhdanov <[hidden email]>
> wrote:
>
> > > I guess it is safe to assume that at this point we came to a consensus?
> >
> > Alex, I think so. Let's carve it in stone (code).
> >
> > --Yakov
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

Ivan Rakov
Guys,

I've attached new configuration design draft to the ticket description:
https://issues.apache.org/jira/browse/IGNITE-6030
Please, take a look. Right now is the best time to change name of any
property.

And question about metrics: are we going to rename MemoryMetrics and
PersistenceMetrics respectively (along with their MBeans)?
It's not a problem to implement it at all. The only thing that concerns
me is that we have to keep deprecated old classes in the codebase.
Perhaps, MemoryMetrics/PersistenceMetrics are intuitive enough.

On 29.09.2017 3:16, Dmitriy Setrakyan wrote:

> StorageRegion sounds like bad English to me.
>
> I would go with DataStorageConfiguration and DataRegionConfiguration.
>
> D.
>
> On Thu, Sep 28, 2017 at 7:24 AM, Vladimir Ozerov <[hidden email]>
> wrote:
>
>> Guys,
>>
>> But what is exact desicion? :-) I saw two final options:
>>
>> 1) StorageConfiguration + StorageRegionConfiguration
>> 2) DataStorageConfiguration + DataRegionConfiguration
>>
>> Which one we choose?
>>
>> On Thu, Sep 28, 2017 at 5:10 PM, Yakov Zhdanov <[hidden email]>
>> wrote:
>>
>>>> I guess it is safe to assume that at this point we came to a consensus?
>>> Alex, I think so. Let's carve it in stone (code).
>>>
>>> --Yakov
>>>

Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

dmagda
Ivan,

Several questions/concerns:

1. Looking at the new API I can’t grasp how to enable the persistence. First, how can I enable it globally if there is only one default data region defined. Second, how do I enable it per data region. Can’t find any related switches in the draft.

2. We cannot renamed anything like you’re suggesting to do for MemoryMetrics and their beans. We have to deprecate old and introduce new.

3. I think we should merge Memory and Persistence Metrics into DataStorageMetrics for clarity.


Denis


> On Sep 29, 2017, at 6:29 AM, Ivan Rakov <[hidden email]> wrote:
>
> Guys,
>
> I've attached new configuration design draft to the ticket description: https://issues.apache.org/jira/browse/IGNITE-6030
> Please, take a look. Right now is the best time to change name of any property.
>
> And question about metrics: are we going to rename MemoryMetrics and PersistenceMetrics respectively (along with their MBeans)?
> It's not a problem to implement it at all. The only thing that concerns me is that we have to keep deprecated old classes in the codebase. Perhaps, MemoryMetrics/PersistenceMetrics are intuitive enough.
>
> On 29.09.2017 3:16, Dmitriy Setrakyan wrote:
>> StorageRegion sounds like bad English to me.
>>
>> I would go with DataStorageConfiguration and DataRegionConfiguration.
>>
>> D.
>>
>> On Thu, Sep 28, 2017 at 7:24 AM, Vladimir Ozerov <[hidden email]>
>> wrote:
>>
>>> Guys,
>>>
>>> But what is exact desicion? :-) I saw two final options:
>>>
>>> 1) StorageConfiguration + StorageRegionConfiguration
>>> 2) DataStorageConfiguration + DataRegionConfiguration
>>>
>>> Which one we choose?
>>>
>>> On Thu, Sep 28, 2017 at 5:10 PM, Yakov Zhdanov <[hidden email]>
>>> wrote:
>>>
>>>>> I guess it is safe to assume that at this point we came to a consensus?
>>>> Alex, I think so. Let's carve it in stone (code).
>>>>
>>>> --Yakov
>>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

Ivan Rakov
Denis,

1) You're right. I forgot to include the main flag in
DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
enabled globally if at least one memory region has this flag set.
Regarding default data region, I've added
*isDefaultDataRegionPersistenceEnabled *to the DataStorageConfiguration.
Check the design draft again.

2) Of course, we have to maintain API compatibility. Deprecating old
classes and introducing new is just what I meant.

3) We can't do that - MemoryMetrics are calculated per memory policy and
PersistenceMetrics are calculated globally. It's a major change to
implement it another way.

By the way, let's assure the namings for new metrics classes.
DataRegionMetrics instead of MemoryMetrics looks fine.
About PersistenceMetrics - name "*DataStorageMetrics*" is not fair
enough as it will contain only metrics of persistent storage. Probably
*DataStoragePersistenceMetrics*,*PersistentDataStorageMetrics *or even
keeping *PersistenceMetrics* are better.

What do you think?

Best Regards,
Ivan Rakov

On 29.09.2017 21:12, Denis Magda wrote:

> Ivan,
>
> Several questions/concerns:
>
> 1. Looking at the new API I can’t grasp how to enable the persistence. First, how can I enable it globally if there is only one default data region defined. Second, how do I enable it per data region. Can’t find any related switches in the draft.
>
> 2. We cannot renamed anything like you’re suggesting to do for MemoryMetrics and their beans. We have to deprecate old and introduce new.
>
> 3. I think we should merge Memory and Persistence Metrics into DataStorageMetrics for clarity.
>
> —
> Denis
>
>
>> On Sep 29, 2017, at 6:29 AM, Ivan Rakov <[hidden email]> wrote:
>>
>> Guys,
>>
>> I've attached new configuration design draft to the ticket description: https://issues.apache.org/jira/browse/IGNITE-6030
>> Please, take a look. Right now is the best time to change name of any property.
>>
>> And question about metrics: are we going to rename MemoryMetrics and PersistenceMetrics respectively (along with their MBeans)?
>> It's not a problem to implement it at all. The only thing that concerns me is that we have to keep deprecated old classes in the codebase. Perhaps, MemoryMetrics/PersistenceMetrics are intuitive enough.
>>
>> On 29.09.2017 3:16, Dmitriy Setrakyan wrote:
>>> StorageRegion sounds like bad English to me.
>>>
>>> I would go with DataStorageConfiguration and DataRegionConfiguration.
>>>
>>> D.
>>>
>>> On Thu, Sep 28, 2017 at 7:24 AM, Vladimir Ozerov <[hidden email]>
>>> wrote:
>>>
>>>> Guys,
>>>>
>>>> But what is exact desicion? :-) I saw two final options:
>>>>
>>>> 1) StorageConfiguration + StorageRegionConfiguration
>>>> 2) DataStorageConfiguration + DataRegionConfiguration
>>>>
>>>> Which one we choose?
>>>>
>>>> On Thu, Sep 28, 2017 at 5:10 PM, Yakov Zhdanov <[hidden email]>
>>>> wrote:
>>>>
>>>>>> I guess it is safe to assume that at this point we came to a consensus?
>>>>> Alex, I think so. Let's carve it in stone (code).
>>>>>
>>>>> --Yakov
>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

Vladimir Ozerov
We merged memory and persistence on config level. So we should merge
metrics in the same way. DataRegionMetrics is absolutely normal name, even
if it contains only persistence-related stuff at the moment.

вс, 1 окт. 2017 г. в 14:41, Ivan Rakov <[hidden email]>:

> Denis,
>
> 1) You're right. I forgot to include the main flag in
> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
> enabled globally if at least one memory region has this flag set.
> Regarding default data region, I've added
> *isDefaultDataRegionPersistenceEnabled *to the DataStorageConfiguration.
> Check the design draft again.
>
> 2) Of course, we have to maintain API compatibility. Deprecating old
> classes and introducing new is just what I meant.
>
> 3) We can't do that - MemoryMetrics are calculated per memory policy and
> PersistenceMetrics are calculated globally. It's a major change to
> implement it another way.
>
> By the way, let's assure the namings for new metrics classes.
> DataRegionMetrics instead of MemoryMetrics looks fine.
> About PersistenceMetrics - name "*DataStorageMetrics*" is not fair
> enough as it will contain only metrics of persistent storage. Probably
> *DataStoragePersistenceMetrics*,*PersistentDataStorageMetrics *or even
> keeping *PersistenceMetrics* are better.
>
> What do you think?
>
> Best Regards,
> Ivan Rakov
>
> On 29.09.2017 21:12, Denis Magda wrote:
> > Ivan,
> >
> > Several questions/concerns:
> >
> > 1. Looking at the new API I can’t grasp how to enable the persistence.
> First, how can I enable it globally if there is only one default data
> region defined. Second, how do I enable it per data region. Can’t find any
> related switches in the draft.
> >
> > 2. We cannot renamed anything like you’re suggesting to do for
> MemoryMetrics and their beans. We have to deprecate old and introduce new.
> >
> > 3. I think we should merge Memory and Persistence Metrics into
> DataStorageMetrics for clarity.
> >
> > —
> > Denis
> >
> >
> >> On Sep 29, 2017, at 6:29 AM, Ivan Rakov <[hidden email]> wrote:
> >>
> >> Guys,
> >>
> >> I've attached new configuration design draft to the ticket description:
> https://issues.apache.org/jira/browse/IGNITE-6030
> >> Please, take a look. Right now is the best time to change name of any
> property.
> >>
> >> And question about metrics: are we going to rename MemoryMetrics and
> PersistenceMetrics respectively (along with their MBeans)?
> >> It's not a problem to implement it at all. The only thing that concerns
> me is that we have to keep deprecated old classes in the codebase. Perhaps,
> MemoryMetrics/PersistenceMetrics are intuitive enough.
> >>
> >> On 29.09.2017 3:16, Dmitriy Setrakyan wrote:
> >>> StorageRegion sounds like bad English to me.
> >>>
> >>> I would go with DataStorageConfiguration and DataRegionConfiguration.
> >>>
> >>> D.
> >>>
> >>> On Thu, Sep 28, 2017 at 7:24 AM, Vladimir Ozerov <[hidden email]
> >
> >>> wrote:
> >>>
> >>>> Guys,
> >>>>
> >>>> But what is exact desicion? :-) I saw two final options:
> >>>>
> >>>> 1) StorageConfiguration + StorageRegionConfiguration
> >>>> 2) DataStorageConfiguration + DataRegionConfiguration
> >>>>
> >>>> Which one we choose?
> >>>>
> >>>> On Thu, Sep 28, 2017 at 5:10 PM, Yakov Zhdanov <[hidden email]>
> >>>> wrote:
> >>>>
> >>>>>> I guess it is safe to assume that at this point we came to a
> consensus?
> >>>>> Alex, I think so. Let's carve it in stone (code).
> >>>>>
> >>>>> --Yakov
> >>>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

Ivan Rakov
Vladimir,

*DataRegionMetrics* is for former memory metrics.
*DataStorageMetrics* will contain metrics about persistence.

If DataStorageMetrics is ok, let's go this way.

Best Regards,
Ivan Rakov

On 01.10.2017 15:19, Vladimir Ozerov wrote:

> We merged memory and persistence on config level. So we should merge
> metrics in the same way. DataRegionMetrics is absolutely normal name, even
> if it contains only persistence-related stuff at the moment.
>
> вс, 1 окт. 2017 г. в 14:41, Ivan Rakov <[hidden email]>:
>
>> Denis,
>>
>> 1) You're right. I forgot to include the main flag in
>> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
>> enabled globally if at least one memory region has this flag set.
>> Regarding default data region, I've added
>> *isDefaultDataRegionPersistenceEnabled *to the DataStorageConfiguration.
>> Check the design draft again.
>>
>> 2) Of course, we have to maintain API compatibility. Deprecating old
>> classes and introducing new is just what I meant.
>>
>> 3) We can't do that - MemoryMetrics are calculated per memory policy and
>> PersistenceMetrics are calculated globally. It's a major change to
>> implement it another way.
>>
>> By the way, let's assure the namings for new metrics classes.
>> DataRegionMetrics instead of MemoryMetrics looks fine.
>> About PersistenceMetrics - name "*DataStorageMetrics*" is not fair
>> enough as it will contain only metrics of persistent storage. Probably
>> *DataStoragePersistenceMetrics*,*PersistentDataStorageMetrics *or even
>> keeping *PersistenceMetrics* are better.
>>
>> What do you think?
>>
>> Best Regards,
>> Ivan Rakov
>>
>> On 29.09.2017 21:12, Denis Magda wrote:
>>> Ivan,
>>>
>>> Several questions/concerns:
>>>
>>> 1. Looking at the new API I can’t grasp how to enable the persistence.
>> First, how can I enable it globally if there is only one default data
>> region defined. Second, how do I enable it per data region. Can’t find any
>> related switches in the draft.
>>> 2. We cannot renamed anything like you’re suggesting to do for
>> MemoryMetrics and their beans. We have to deprecate old and introduce new.
>>> 3. I think we should merge Memory and Persistence Metrics into
>> DataStorageMetrics for clarity.
>>> —
>>> Denis
>>>
>>>
>>>> On Sep 29, 2017, at 6:29 AM, Ivan Rakov <[hidden email]> wrote:
>>>>
>>>> Guys,
>>>>
>>>> I've attached new configuration design draft to the ticket description:
>> https://issues.apache.org/jira/browse/IGNITE-6030
>>>> Please, take a look. Right now is the best time to change name of any
>> property.
>>>> And question about metrics: are we going to rename MemoryMetrics and
>> PersistenceMetrics respectively (along with their MBeans)?
>>>> It's not a problem to implement it at all. The only thing that concerns
>> me is that we have to keep deprecated old classes in the codebase. Perhaps,
>> MemoryMetrics/PersistenceMetrics are intuitive enough.
>>>> On 29.09.2017 3:16, Dmitriy Setrakyan wrote:
>>>>> StorageRegion sounds like bad English to me.
>>>>>
>>>>> I would go with DataStorageConfiguration and DataRegionConfiguration.
>>>>>
>>>>> D.
>>>>>
>>>>> On Thu, Sep 28, 2017 at 7:24 AM, Vladimir Ozerov <[hidden email]
>>>>> wrote:
>>>>>
>>>>>> Guys,
>>>>>>
>>>>>> But what is exact desicion? :-) I saw two final options:
>>>>>>
>>>>>> 1) StorageConfiguration + StorageRegionConfiguration
>>>>>> 2) DataStorageConfiguration + DataRegionConfiguration
>>>>>>
>>>>>> Which one we choose?
>>>>>>
>>>>>> On Thu, Sep 28, 2017 at 5:10 PM, Yakov Zhdanov <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>>> I guess it is safe to assume that at this point we came to a
>> consensus?
>>>>>>> Alex, I think so. Let's carve it in stone (code).
>>>>>>>
>>>>>>> --Yakov
>>>>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

dsetrakyan
In reply to this post by Ivan Rakov
I am not sure I like the name "isDefaultDataRegionPersistenceEnabled" - too
long. Can we just call it "isDefaultPersistenceEnabled"?

D.

On Sun, Oct 1, 2017 at 2:41 PM, Ivan Rakov <[hidden email]> wrote:

> Denis,
>
> 1) You're right. I forgot to include the main flag in
> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
> enabled globally if at least one memory region has this flag set.
> Regarding default data region, I've added *isDefaultDataRegionPersistenceEnabled
> *to the DataStorageConfiguration. Check the design draft again.
>
> 2) Of course, we have to maintain API compatibility. Deprecating old
> classes and introducing new is just what I meant.
>
> 3) We can't do that - MemoryMetrics are calculated per memory policy and
> PersistenceMetrics are calculated globally. It's a major change to
> implement it another way.
>
> By the way, let's assure the namings for new metrics classes.
> DataRegionMetrics instead of MemoryMetrics looks fine.
> About PersistenceMetrics - name "*DataStorageMetrics*" is not fair enough
> as it will contain only metrics of persistent storage. Probably
> *DataStoragePersistenceMetrics*,*PersistentDataStorageMetrics *or even
> keeping *PersistenceMetrics* are better.
>
> What do you think?
>
> Best Regards,
> Ivan Rakov
>
>
> On 29.09.2017 21:12, Denis Magda wrote:
>
>> Ivan,
>>
>> Several questions/concerns:
>>
>> 1. Looking at the new API I can’t grasp how to enable the persistence.
>> First, how can I enable it globally if there is only one default data
>> region defined. Second, how do I enable it per data region. Can’t find any
>> related switches in the draft.
>>
>> 2. We cannot renamed anything like you’re suggesting to do for
>> MemoryMetrics and their beans. We have to deprecate old and introduce new.
>>
>> 3. I think we should merge Memory and Persistence Metrics into
>> DataStorageMetrics for clarity.
>>
>> —
>> Denis
>>
>>
>> On Sep 29, 2017, at 6:29 AM, Ivan Rakov <[hidden email]> wrote:
>>>
>>> Guys,
>>>
>>> I've attached new configuration design draft to the ticket description:
>>> https://issues.apache.org/jira/browse/IGNITE-6030
>>> Please, take a look. Right now is the best time to change name of any
>>> property.
>>>
>>> And question about metrics: are we going to rename MemoryMetrics and
>>> PersistenceMetrics respectively (along with their MBeans)?
>>> It's not a problem to implement it at all. The only thing that concerns
>>> me is that we have to keep deprecated old classes in the codebase. Perhaps,
>>> MemoryMetrics/PersistenceMetrics are intuitive enough.
>>>
>>> On 29.09.2017 3:16, Dmitriy Setrakyan wrote:
>>>
>>>> StorageRegion sounds like bad English to me.
>>>>
>>>> I would go with DataStorageConfiguration and DataRegionConfiguration.
>>>>
>>>> D.
>>>>
>>>> On Thu, Sep 28, 2017 at 7:24 AM, Vladimir Ozerov <[hidden email]>
>>>> wrote:
>>>>
>>>> Guys,
>>>>>
>>>>> But what is exact desicion? :-) I saw two final options:
>>>>>
>>>>> 1) StorageConfiguration + StorageRegionConfiguration
>>>>> 2) DataStorageConfiguration + DataRegionConfiguration
>>>>>
>>>>> Which one we choose?
>>>>>
>>>>> On Thu, Sep 28, 2017 at 5:10 PM, Yakov Zhdanov <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> I guess it is safe to assume that at this point we came to a consensus?
>>>>>>>
>>>>>> Alex, I think so. Let's carve it in stone (code).
>>>>>>
>>>>>> --Yakov
>>>>>>
>>>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

dmagda
In reply to this post by Ivan Rakov

> On Oct 1, 2017, at 4:41 AM, Ivan Rakov <[hidden email]> wrote:
>
> 1) You're right. I forgot to include the main flag in DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be enabled globally if at least one memory region has this flag set.

I’m confused. Why the persistence should be enabled *globally* if the purpose is to have it set for a specific region? If it’s enabled for region A only, I don’t want to have it activated for region B.


Denis
 
Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

dsetrakyan
On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda <[hidden email]> wrote:

>
> > On Oct 1, 2017, at 4:41 AM, Ivan Rakov <[hidden email]> wrote:
> >
> > 1) You're right. I forgot to include the main flag in
> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
> enabled globally if at least one memory region has this flag set.
>
> I’m confused. Why the persistence should be enabled *globally* if the
> purpose is to have it set for a specific region? If it’s enabled for region
> A only, I don’t want to have it activated for region B.
>

Yes, you are right. By default the persistence will be disabled globally.
But we should also give users a way to switch the default behavior from
in-memory only (no-persistence) to persistence.
Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

dmagda

> On Oct 1, 2017, at 9:49 PM, Dmitriy Setrakyan <[hidden email]> wrote:
>
> On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda <[hidden email] <mailto:[hidden email]>> wrote:
>
>>
>>> On Oct 1, 2017, at 4:41 AM, Ivan Rakov <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>> 1) You're right. I forgot to include the main flag in
>> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
>> enabled globally if at least one memory region has this flag set.
>>
>> I’m confused. Why the persistence should be enabled *globally* if the
>> purpose is to have it set for a specific region? If it’s enabled for region
>> A only, I don’t want to have it activated for region B.
>>
>
> Yes, you are right. By default the persistence will be disabled globally.
> But we should also give users a way to switch the default behavior from
> in-memory only (no-persistence) to persistence.

Sure, that’s how it was discussed initially. Basically, at the API level we should have:

1. DataRegionConfigurations.isPersistenceEnabled - that turns on/off the persistence per region.

2. DataStorageConfiguration.isPersistenceEnabled - that does this globally except for regions disabled it explicitly via 1.

My confusion is caused by Ivan’s allegation that as soon as the persistence is enabled at least for one region via 1 the persistence will be globally activated for the rest (as I would enable it via 2). Ivan did I get your words in a right way?


Denis
Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

Ivan Rakov
In reply to this post by dsetrakyan
Guys, I think I got the point now.

Let's check the final design:

*DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
property (default = false), which will be used for enabling persistence
in default data region.
*DataRegionConfiguration* will have *isPersistenceEnabled* property,
which will be used for enabling persistence in corresponding data
region. If value is not set, value of
*DataStorageConfiguration::isDefaultPersistenceEnabled* will be used by
default.

Best Regards,
Ivan Rakov


On 02.10.2017 7:49, Dmitriy Setrakyan wrote:

> On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda <[hidden email]> wrote:
>
>>> On Oct 1, 2017, at 4:41 AM, Ivan Rakov <[hidden email]> wrote:
>>>
>>> 1) You're right. I forgot to include the main flag in
>> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
>> enabled globally if at least one memory region has this flag set.
>>
>> I’m confused. Why the persistence should be enabled *globally* if the
>> purpose is to have it set for a specific region? If it’s enabled for region
>> A only, I don’t want to have it activated for region B.
>>
> Yes, you are right. By default the persistence will be disabled globally.
> But we should also give users a way to switch the default behavior from
> in-memory only (no-persistence) to persistence.
>

Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

Vladimir Ozerov
Ivan,

I do not think this is correct approach, because it will be hard to
explain, and you will have to use "Boolean" instead of "boolean" for
DataRegionConfiguration. I do not think we need default "persistence
enabled" for all regions. Instead, we should have "persistence enabled"
flag for default region only. It should not be propagated to custom regions.

On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov <[hidden email]> wrote:

> Guys, I think I got the point now.
>
> Let's check the final design:
>
> *DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
> property (default = false), which will be used for enabling persistence in
> default data region.
> *DataRegionConfiguration* will have *isPersistenceEnabled* property, which
> will be used for enabling persistence in corresponding data region. If
> value is not set, value of *DataStorageConfiguration::isDefaultPersistenceEnabled*
> will be used by default.
>
> Best Regards,
> Ivan Rakov
>
>
>
> On 02.10.2017 7:49, Dmitriy Setrakyan wrote:
>
>> On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda <[hidden email]> wrote:
>>
>> On Oct 1, 2017, at 4:41 AM, Ivan Rakov <[hidden email]> wrote:
>>>>
>>>> 1) You're right. I forgot to include the main flag in
>>>>
>>> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
>>> enabled globally if at least one memory region has this flag set.
>>>
>>> I’m confused. Why the persistence should be enabled *globally* if the
>>> purpose is to have it set for a specific region? If it’s enabled for
>>> region
>>> A only, I don’t want to have it activated for region B.
>>>
>>> Yes, you are right. By default the persistence will be disabled globally.
>> But we should also give users a way to switch the default behavior from
>> in-memory only (no-persistence) to persistence.
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

Ivan Rakov
Vladimir,

I like your approach because it's easier to implement.

However, user may be confused by setting *isDefaultPersistenceEnabled*
flag and seeing that persistence is not enabled by default in custom
memory region. I'll add clarifying Javadoc at this place.

Best Regards,
Ivan Rakov

On 02.10.2017 11:28, Vladimir Ozerov wrote:

> Ivan,
>
> I do not think this is correct approach, because it will be hard to
> explain, and you will have to use "Boolean" instead of "boolean" for
> DataRegionConfiguration. I do not think we need default "persistence
> enabled" for all regions. Instead, we should have "persistence enabled"
> flag for default region only. It should not be propagated to custom regions.
>
> On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov <[hidden email]> wrote:
>
>> Guys, I think I got the point now.
>>
>> Let's check the final design:
>>
>> *DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
>> property (default = false), which will be used for enabling persistence in
>> default data region.
>> *DataRegionConfiguration* will have *isPersistenceEnabled* property, which
>> will be used for enabling persistence in corresponding data region. If
>> value is not set, value of *DataStorageConfiguration::isDefaultPersistenceEnabled*
>> will be used by default.
>>
>> Best Regards,
>> Ivan Rakov
>>
>>
>>
>> On 02.10.2017 7:49, Dmitriy Setrakyan wrote:
>>
>>> On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda <[hidden email]> wrote:
>>>
>>> On Oct 1, 2017, at 4:41 AM, Ivan Rakov <[hidden email]> wrote:
>>>>> 1) You're right. I forgot to include the main flag in
>>>>>
>>>> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
>>>> enabled globally if at least one memory region has this flag set.
>>>>
>>>> I’m confused. Why the persistence should be enabled *globally* if the
>>>> purpose is to have it set for a specific region? If it’s enabled for
>>>> region
>>>> A only, I don’t want to have it activated for region B.
>>>>
>>>> Yes, you are right. By default the persistence will be disabled globally.
>>> But we should also give users a way to switch the default behavior from
>>> in-memory only (no-persistence) to persistence.
>>>
>>>

Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

Alexey Goncharuk
Agree with Vladimir. If we are to implement this, we would either need to
have a Boolean (non-primitive) for persistenceEnabled on
DataRegionConfiguration, or introduce an enum for this field which is also
an overkill. On the other hand, one can assume that the defaults we are
talking about are actually inherited. To resolve this, I suggest to
introduce just another field defaultRegionConfiguration and get rid of
other defaults in DataStorageConfiguration.

Thoughts?

2017-10-02 15:19 GMT+03:00 Ivan Rakov <[hidden email]>:

> Vladimir,
>
> I like your approach because it's easier to implement.
>
> However, user may be confused by setting *isDefaultPersistenceEnabled*
> flag and seeing that persistence is not enabled by default in custom memory
> region. I'll add clarifying Javadoc at this place.
>
> Best Regards,
> Ivan Rakov
>
>
> On 02.10.2017 11:28, Vladimir Ozerov wrote:
>
>> Ivan,
>>
>> I do not think this is correct approach, because it will be hard to
>> explain, and you will have to use "Boolean" instead of "boolean" for
>> DataRegionConfiguration. I do not think we need default "persistence
>> enabled" for all regions. Instead, we should have "persistence enabled"
>> flag for default region only. It should not be propagated to custom
>> regions.
>>
>> On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov <[hidden email]>
>> wrote:
>>
>> Guys, I think I got the point now.
>>>
>>> Let's check the final design:
>>>
>>> *DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
>>> property (default = false), which will be used for enabling persistence
>>> in
>>> default data region.
>>> *DataRegionConfiguration* will have *isPersistenceEnabled* property,
>>> which
>>> will be used for enabling persistence in corresponding data region. If
>>> value is not set, value of *DataStorageConfiguration::isD
>>> efaultPersistenceEnabled*
>>> will be used by default.
>>>
>>> Best Regards,
>>> Ivan Rakov
>>>
>>>
>>>
>>> On 02.10.2017 7:49, Dmitriy Setrakyan wrote:
>>>
>>> On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda <[hidden email]> wrote:
>>>>
>>>> On Oct 1, 2017, at 4:41 AM, Ivan Rakov <[hidden email]> wrote:
>>>>
>>>>> 1) You're right. I forgot to include the main flag in
>>>>>>
>>>>>> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
>>>>> enabled globally if at least one memory region has this flag set.
>>>>>
>>>>> I’m confused. Why the persistence should be enabled *globally* if the
>>>>> purpose is to have it set for a specific region? If it’s enabled for
>>>>> region
>>>>> A only, I don’t want to have it activated for region B.
>>>>>
>>>>> Yes, you are right. By default the persistence will be disabled
>>>>> globally.
>>>>>
>>>> But we should also give users a way to switch the default behavior from
>>>> in-memory only (no-persistence) to persistence.
>>>>
>>>>
>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Persistence per memory policy configuration

dmagda
> To resolve this, I suggest to
> introduce just another field defaultRegionConfiguration and get rid of
> other defaults in DataStorageConfiguration.

Won’t it complicate the configuration from a Spring XML file? I’m not an expert in Spring so how do I get defaultRegionConfiguration bean first to change any parameter?


Denis

> On Oct 2, 2017, at 8:30 AM, Alexey Goncharuk <[hidden email]> wrote:
>
> Agree with Vladimir. If we are to implement this, we would either need to
> have a Boolean (non-primitive) for persistenceEnabled on
> DataRegionConfiguration, or introduce an enum for this field which is also
> an overkill. On the other hand, one can assume that the defaults we are
> talking about are actually inherited. To resolve this, I suggest to
> introduce just another field defaultRegionConfiguration and get rid of
> other defaults in DataStorageConfiguration.
>
> Thoughts?
>
> 2017-10-02 15:19 GMT+03:00 Ivan Rakov <[hidden email]>:
>
>> Vladimir,
>>
>> I like your approach because it's easier to implement.
>>
>> However, user may be confused by setting *isDefaultPersistenceEnabled*
>> flag and seeing that persistence is not enabled by default in custom memory
>> region. I'll add clarifying Javadoc at this place.
>>
>> Best Regards,
>> Ivan Rakov
>>
>>
>> On 02.10.2017 11:28, Vladimir Ozerov wrote:
>>
>>> Ivan,
>>>
>>> I do not think this is correct approach, because it will be hard to
>>> explain, and you will have to use "Boolean" instead of "boolean" for
>>> DataRegionConfiguration. I do not think we need default "persistence
>>> enabled" for all regions. Instead, we should have "persistence enabled"
>>> flag for default region only. It should not be propagated to custom
>>> regions.
>>>
>>> On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov <[hidden email]>
>>> wrote:
>>>
>>> Guys, I think I got the point now.
>>>>
>>>> Let's check the final design:
>>>>
>>>> *DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
>>>> property (default = false), which will be used for enabling persistence
>>>> in
>>>> default data region.
>>>> *DataRegionConfiguration* will have *isPersistenceEnabled* property,
>>>> which
>>>> will be used for enabling persistence in corresponding data region. If
>>>> value is not set, value of *DataStorageConfiguration::isD
>>>> efaultPersistenceEnabled*
>>>> will be used by default.
>>>>
>>>> Best Regards,
>>>> Ivan Rakov
>>>>
>>>>
>>>>
>>>> On 02.10.2017 7:49, Dmitriy Setrakyan wrote:
>>>>
>>>> On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda <[hidden email]> wrote:
>>>>>
>>>>> On Oct 1, 2017, at 4:41 AM, Ivan Rakov <[hidden email]> wrote:
>>>>>
>>>>>> 1) You're right. I forgot to include the main flag in
>>>>>>>
>>>>>>> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
>>>>>> enabled globally if at least one memory region has this flag set.
>>>>>>
>>>>>> I’m confused. Why the persistence should be enabled *globally* if the
>>>>>> purpose is to have it set for a specific region? If it’s enabled for
>>>>>> region
>>>>>> A only, I don’t want to have it activated for region B.
>>>>>>
>>>>>> Yes, you are right. By default the persistence will be disabled
>>>>>> globally.
>>>>>>
>>>>> But we should also give users a way to switch the default behavior from
>>>>> in-memory only (no-persistence) to persistence.
>>>>>
>>>>>
>>>>>
>>

12345