Configuration inconsistency

[Valentin Kulichenko]

Guys,

I noticed that some entities on cache configuration are configured via
factories, while others are set directly. For example, we use factory for
ExpiryPolicy, but not for EvictionPolicy, which looks inconsistent. Since
factory-based approach comes from JCache, I think we should use it wherever
possible.

Here is the list of settings that need to be fixed (I checked only cache
config):

   - Affinity
   - AffinityMapper
   - EvictionFilter
   - EvictionPolicy
   - CacheInterceptor
   - TopologyValidator

Agree?

--
Val

[yzhdanov]

I think this is a very good point. Val, please file a ticket.

--Yakov

2015-05-09 3:45 GMT+03:00 Valentin Kulichenko <[hidden email]
>:

> Guys,
>
> I noticed that some entities on cache configuration are configured via
> factories, while others are set directly. For example, we use factory for
> ExpiryPolicy, but not for EvictionPolicy, which looks inconsistent. Since
> factory-based approach comes from JCache, I think we should use it wherever
> possible.
>
> Here is the list of settings that need to be fixed (I checked only cache
> config):
>
>    - Affinity
>    - AffinityMapper
>    - EvictionFilter
>    - EvictionPolicy
>    - CacheInterceptor
>    - TopologyValidator
>
> Agree?
>
> --
> Val
>

[dsetrakyan]

In my view, such refactoring will make cache configuration very hard to
use. My preference would be to leave it as is and wait for more user
feedback.

On Tue, May 12, 2015 at 1:21 PM, Yakov Zhdanov <[hidden email]> wrote:

> I think this is a very good point. Val, please file a ticket.
>
> --Yakov
>
> 2015-05-09 3:45 GMT+03:00 Valentin Kulichenko <
> [hidden email]
> >:
>
> > Guys,
> >
> > I noticed that some entities on cache configuration are configured via
> > factories, while others are set directly. For example, we use factory for
> > ExpiryPolicy, but not for EvictionPolicy, which looks inconsistent. Since
> > factory-based approach comes from JCache, I think we should use it
> wherever
> > possible.
> >
> > Here is the list of settings that need to be fixed (I checked only cache
> > config):
> >
> >    - Affinity
> >    - AffinityMapper
> >    - EvictionFilter
> >    - EvictionPolicy
> >    - CacheInterceptor
> >    - TopologyValidator
> >
> > Agree?
> >
> > --
> > Val
> >
>

[Valentin Kulichenko]

I already created a ticket ​anyway (can cloase it if we decide not to fix):
https://issues.apache.org/jira/browse/IGNITE-896

There is one more issue here: we require cache configuration to be
serializable for dynamic cache support. So if eviction policy, for example,
depends on some non-serializable objects, it will be very hard to
configure. It's probably a very rare use case, but we need to keep it in
mind.

--
Val

[dsetrakyan]

On Tue, May 12, 2015 at 2:45 PM, Valentin Kulichenko <
[hidden email]> wrote:

> I already created a ticket ​anyway (can cloase it if we decide not to fix):
> https://issues.apache.org/jira/browse/IGNITE-896
>
> There is one more issue here: we require cache configuration to be
> serializable for dynamic cache support. So if eviction policy, for example,
> depends on some non-serializable objects, it will be very hard to
> configure. It's probably a very rare use case, but we need to keep it in
> mind.
>

This is a good point. I think we should make everything that can end up in
configuration as  Serializable. Would this be possible for eviction policy?



>
> --
> Val
>

[Valentin Kulichenko]

All our implementations are Serializable. But we don't know anything about
user's implementations.

--
Val

On Tue, May 12, 2015 at 11:50 AM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Tue, May 12, 2015 at 2:45 PM, Valentin Kulichenko <
> [hidden email]> wrote:
>
> > I already created a ticket ​anyway (can cloase it if we decide not to
> fix):
> > https://issues.apache.org/jira/browse/IGNITE-896
> >
> > There is one more issue here: we require cache configuration to be
> > serializable for dynamic cache support. So if eviction policy, for
> example,
> > depends on some non-serializable objects, it will be very hard to
> > configure. It's probably a very rare use case, but we need to keep it in
> > mind.
> >
>
> This is a good point. I think we should make everything that can end up in
> configuration as  Serializable. Would this be possible for eviction policy?
>
>
>
> >
> > --
> > Val
> >
>

[yzhdanov]

This is one more argument to move to factories.

--Yakov

2015-05-13 6:02 GMT+03:00 Valentin Kulichenko <[hidden email]
>:

> All our implementations are Serializable. But we don't know anything about
> user's implementations.
>
> --
> Val
>
> On Tue, May 12, 2015 at 11:50 AM, Dmitriy Setrakyan <[hidden email]
> >
> wrote:
>
> > On Tue, May 12, 2015 at 2:45 PM, Valentin Kulichenko <
> > [hidden email]> wrote:
> >
> > > I already created a ticket ​anyway (can cloase it if we decide not to
> > fix):
> > > https://issues.apache.org/jira/browse/IGNITE-896
> > >
> > > There is one more issue here: we require cache configuration to be
> > > serializable for dynamic cache support. So if eviction policy, for
> > example,
> > > depends on some non-serializable objects, it will be very hard to
> > > configure. It's probably a very rare use case, but we need to keep it
> in
> > > mind.
> > >
> >
> > This is a good point. I think we should make everything that can end up
> in
> > configuration as  Serializable. Would this be possible for eviction
> policy?
> >
> >
> >
> > >
> > > --
> > > Val
> > >
> >
>