Expiry policy for Cache.invoke

[Denis Mekhanikov]

Igniters!

I noticed a weird behavior regarding expiry policy in Ignite. You can find an example in the attachment.

When you call invoke on a cache with configured CacheStore and ExpiryPolicy, then chosen expiry depends on cache's atomicity mode.

If cache is atomic, then "creation" expiry timeout is chosen, but if it is transactional - then "access".

I think, this behavior should at least be identical in both cases, but what is more important, it should conform to JCache specification.

But I wasn't able to find a clear statement regarding this question in the specification. Can somebody point out a place in the specification that defines a behavior in such case?

Cheers,

Denis

[dsetrakyan]

Denis,

I agree that the behavior should be consistent, but you will not find
anything about transactions in JCache. To my knowledge, JCache does not
have transactions.

I would file a ticket about the issue you found, so the community could
address it. If you are interested, perhaps you can contribute a fix
yourself.

Thanks,
D.

On Wed, Sep 13, 2017 at 5:47 AM, Denis Mekhanikov <[hidden email]>
wrote:

> Igniters!
>
> I noticed a weird behavior regarding expiry policy in Ignite. You can find
> an example in the attachment.
> When you call invoke on a cache with configured CacheStore and
> ExpiryPolicy, then chosen expiry depends on cache's atomicity mode.
> If cache is atomic, then "creation" expiry timeout is chosen, but if it is
> transactional - then "access".
>
> I think, this behavior should at least be identical in both cases, but
> what is more important, it should conform to JCache specification.
> But I wasn't able to find a clear statement regarding this question in the
> specification. Can somebody point out a place in the specification that
> defines a behavior in such case?
>
> Cheers,
> Denis
>

[Valentin Kulichenko]

Denis,

I'm confused by the issue. Do you mean that we can use expiry policy other
than the one provided in configuration? How is this possible? Can you point
to the code that implements this logic?

-Val

On Wed, Sep 13, 2017 at 11:29 AM, Dmitriy Setrakyan <[hidden email]>
wrote:

> Denis,
>
> I agree that the behavior should be consistent, but you will not find
> anything about transactions in JCache. To my knowledge, JCache does not
> have transactions.
>
> I would file a ticket about the issue you found, so the community could
> address it. If you are interested, perhaps you can contribute a fix
> yourself.
>
> Thanks,
> D.
>
> On Wed, Sep 13, 2017 at 5:47 AM, Denis Mekhanikov <[hidden email]>
> wrote:
>
> > Igniters!
> >
> > I noticed a weird behavior regarding expiry policy in Ignite. You can
> find
> > an example in the attachment.
> > When you call invoke on a cache with configured CacheStore and
> > ExpiryPolicy, then chosen expiry depends on cache's atomicity mode.
> > If cache is atomic, then "creation" expiry timeout is chosen, but if it
> is
> > transactional - then "access".
> >
> > I think, this behavior should at least be identical in both cases, but
> > what is more important, it should conform to JCache specification.
> > But I wasn't able to find a clear statement regarding this question in
> the
> > specification. Can somebody point out a place in the specification that
> > defines a behavior in such case?
> >
> > Cheers,
> > Denis
> >
>

[Denis Mekhanikov]

Val,

Sorry, I may be didn't formulate the issue clearly. Other than predefined
expiry policies (like CreatedExpiryPolicy, AccessedExpiryPolicy, etc) you
can provide a custom expiry policy by calling
setExpiryPolicyFactory(Factory<ExpiryPolicy>)
<https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/CacheConfiguration.html#setExpiryPolicyFactory(javax.cache.configuration.Factory)>.
So, cache will consult the configured ExpiryPolicy by calling
getExpiryForCreation(), getExpiryForAccess() or getExpiryForUpdate(),
depending on the performed operation.

So, the methods of ExpiryPolicy that are called when invoke(...)
<https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#invoke(K,%20org.apache.ignite.cache.CacheEntryProcessor,%20java.lang.Object...)>
is
used, somehow depend on the configured atomicity. Of course, the configured
ExpiryPolicy is used, but in some cases the wrong method is called.

Denis

чт, 14 сент. 2017 г. в 1:54, Valentin Kulichenko <
[hidden email]>:

> Denis,
>
> I'm confused by the issue. Do you mean that we can use expiry policy other
> than the one provided in configuration? How is this possible? Can you point
> to the code that implements this logic?
>
> -Val
>
> On Wed, Sep 13, 2017 at 11:29 AM, Dmitriy Setrakyan <[hidden email]
> >
> wrote:
>
> > Denis,
> >
> > I agree that the behavior should be consistent, but you will not find
> > anything about transactions in JCache. To my knowledge, JCache does not
> > have transactions.
> >
> > I would file a ticket about the issue you found, so the community could
> > address it. If you are interested, perhaps you can contribute a fix
> > yourself.
> >
> > Thanks,
> > D.
> >
> > On Wed, Sep 13, 2017 at 5:47 AM, Denis Mekhanikov <[hidden email]
> >
> > wrote:
> >
> > > Igniters!
> > >
> > > I noticed a weird behavior regarding expiry policy in Ignite. You can
> > find
> > > an example in the attachment.
> > > When you call invoke on a cache with configured CacheStore and
> > > ExpiryPolicy, then chosen expiry depends on cache's atomicity mode.
> > > If cache is atomic, then "creation" expiry timeout is chosen, but if it
> > is
> > > transactional - then "access".
> > >
> > > I think, this behavior should at least be identical in both cases, but
> > > what is more important, it should conform to JCache specification.
> > > But I wasn't able to find a clear statement regarding this question in
> > the
> > > specification. Can somebody point out a place in the specification that
> > > defines a behavior in such case?
> > >
> > > Cheers,
> > > Denis
> > >
> >
>

[Denis Mekhanikov]

Dmitriy,

You are right about transactions, but the spec describes invoke, so, if it
specifies some behavior in general, then it should be followed in both
cases.

Here is the most relevant part I could find in the spec:
https://static.javadoc.io/javax.cache/cache-api/1.0.0/javax/cache/processor/EntryProcessor.html
I think, that if the value is loaded from CacheStore, then
getExpiryForCreation() should be used. Other methods should be called
depending on operations performed.

Denis

чт, 14 сент. 2017 г. в 12:02, Denis Mekhanikov <[hidden email]>:

> Val,
>
> Sorry, I may be didn't formulate the issue clearly. Other than predefined
> expiry policies (like CreatedExpiryPolicy, AccessedExpiryPolicy, etc) you
> can provide a custom expiry policy by calling
> setExpiryPolicyFactory(Factory<ExpiryPolicy>)
> <https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/CacheConfiguration.html#setExpiryPolicyFactory(javax.cache.configuration.Factory)>.
> So, cache will consult the configured ExpiryPolicy by calling
> getExpiryForCreation(), getExpiryForAccess() or getExpiryForUpdate(),
> depending on the performed operation.
>
> So, the methods of ExpiryPolicy that are called when invoke(...)
> <https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#invoke(K,%20org.apache.ignite.cache.CacheEntryProcessor,%20java.lang.Object...)> is
> used, somehow depend on the configured atomicity. Of course, the configured
> ExpiryPolicy is used, but in some cases the wrong method is called.
>
> Denis
>
> чт, 14 сент. 2017 г. в 1:54, Valentin Kulichenko <
> [hidden email]>:
>
>> Denis,
>>
>> I'm confused by the issue. Do you mean that we can use expiry policy other
>> than the one provided in configuration? How is this possible? Can you
>> point
>> to the code that implements this logic?
>>
>> -Val
>>
>> On Wed, Sep 13, 2017 at 11:29 AM, Dmitriy Setrakyan <
>> [hidden email]>
>> wrote:
>>
>> > Denis,
>> >
>> > I agree that the behavior should be consistent, but you will not find
>> > anything about transactions in JCache. To my knowledge, JCache does not
>> > have transactions.
>> >
>> > I would file a ticket about the issue you found, so the community could
>> > address it. If you are interested, perhaps you can contribute a fix
>> > yourself.
>> >
>> > Thanks,
>> > D.
>> >
>> > On Wed, Sep 13, 2017 at 5:47 AM, Denis Mekhanikov <
>> [hidden email]>
>> > wrote:
>> >
>> > > Igniters!
>> > >
>> > > I noticed a weird behavior regarding expiry policy in Ignite. You can
>> > find
>> > > an example in the attachment.
>> > > When you call invoke on a cache with configured CacheStore and
>> > > ExpiryPolicy, then chosen expiry depends on cache's atomicity mode.
>> > > If cache is atomic, then "creation" expiry timeout is chosen, but if
>> it
>> > is
>> > > transactional - then "access".
>> > >
>> > > I think, this behavior should at least be identical in both cases, but
>> > > what is more important, it should conform to JCache specification.
>> > > But I wasn't able to find a clear statement regarding this question in
>> > the
>> > > specification. Can somebody point out a place in the specification
>> that
>> > > defines a behavior in such case?
>> > >
>> > > Cheers,
>> > > Denis
>> > >
>> >
>>
>

[Valentin Kulichenko]

Denis,

This looks like a bug. In my understanding, getExpiryForAccess should be
called for any update, plus one of getExpiryForCreation/getExpiryForUpdate
depending on whether it's a new entry or not. And this definitely should
not depend on cache mode.

-Val

On Thu, Sep 14, 2017 at 3:02 AM, Denis Mekhanikov <[hidden email]>
wrote:

> Dmitriy,
>
> You are right about transactions, but the spec describes invoke, so, if it
> specifies some behavior in general, then it should be followed in both
> cases.
>
> Here is the most relevant part I could find in the spec:
> https://static.javadoc.io/javax.cache/cache-api/1.0.0/
> javax/cache/processor/EntryProcessor.html
> I think, that if the value is loaded from CacheStore, then
> getExpiryForCreation() should be used. Other methods should be called
> depending on operations performed.
>
> Denis
>
> чт, 14 сент. 2017 г. в 12:02, Denis Mekhanikov <[hidden email]>:
>
> > Val,
> >
> > Sorry, I may be didn't formulate the issue clearly. Other than predefined
> > expiry policies (like CreatedExpiryPolicy, AccessedExpiryPolicy, etc) you
> > can provide a custom expiry policy by calling
> > setExpiryPolicyFactory(Factory<ExpiryPolicy>)
> > <https://ignite.apache.org/releases/latest/javadoc/org/
> apache/ignite/configuration/CacheConfiguration.html#
> setExpiryPolicyFactory(javax.cache.configuration.Factory)>.
> > So, cache will consult the configured ExpiryPolicy by calling
> > getExpiryForCreation(), getExpiryForAccess() or getExpiryForUpdate(),
> > depending on the performed operation.
> >
> > So, the methods of ExpiryPolicy that are called when invoke(...)
> > <https://ignite.apache.org/releases/latest/javadoc/org/
> apache/ignite/IgniteCache.html#invoke(K,%20org.apache.ignite.cache.
> CacheEntryProcessor,%20java.lang.Object...)> is
> > used, somehow depend on the configured atomicity. Of course, the
> configured
> > ExpiryPolicy is used, but in some cases the wrong method is called.
> >
> > Denis
> >
> > чт, 14 сент. 2017 г. в 1:54, Valentin Kulichenko <
> > [hidden email]>:
> >
> >> Denis,
> >>
> >> I'm confused by the issue. Do you mean that we can use expiry policy
> other
> >> than the one provided in configuration? How is this possible? Can you
> >> point
> >> to the code that implements this logic?
> >>
> >> -Val
> >>
> >> On Wed, Sep 13, 2017 at 11:29 AM, Dmitriy Setrakyan <
> >> [hidden email]>
> >> wrote:
> >>
> >> > Denis,
> >> >
> >> > I agree that the behavior should be consistent, but you will not find
> >> > anything about transactions in JCache. To my knowledge, JCache does
> not
> >> > have transactions.
> >> >
> >> > I would file a ticket about the issue you found, so the community
> could
> >> > address it. If you are interested, perhaps you can contribute a fix
> >> > yourself.
> >> >
> >> > Thanks,
> >> > D.
> >> >
> >> > On Wed, Sep 13, 2017 at 5:47 AM, Denis Mekhanikov <
> >> [hidden email]>
> >> > wrote:
> >> >
> >> > > Igniters!
> >> > >
> >> > > I noticed a weird behavior regarding expiry policy in Ignite. You
> can
> >> > find
> >> > > an example in the attachment.
> >> > > When you call invoke on a cache with configured CacheStore and
> >> > > ExpiryPolicy, then chosen expiry depends on cache's atomicity mode.
> >> > > If cache is atomic, then "creation" expiry timeout is chosen, but if
> >> it
> >> > is
> >> > > transactional - then "access".
> >> > >
> >> > > I think, this behavior should at least be identical in both cases,
> but
> >> > > what is more important, it should conform to JCache specification.
> >> > > But I wasn't able to find a clear statement regarding this question
> in
> >> > the
> >> > > specification. Can somebody point out a place in the specification
> >> that
> >> > > defines a behavior in such case?
> >> > >
> >> > > Cheers,
> >> > > Denis
> >> > >
> >> >
> >>
> >
>

[Denis Mekhanikov]

I filed a ticket for this issue:
https://issues.apache.org/jira/browse/IGNITE-6388

Also I stumbled upon another bug, trying to reproduce the previous one.
Here is a ticket: https://issues.apache.org/jira/browse/IGNITE-6389

Denis

пт, 15 сент. 2017 г. в 3:07, Valentin Kulichenko <
[hidden email]>:

> Denis,
>
> This looks like a bug. In my understanding, getExpiryForAccess should be
> called for any update, plus one of getExpiryForCreation/getExpiryForUpdate
> depending on whether it's a new entry or not. And this definitely should
> not depend on cache mode.
>
> -Val
>
> On Thu, Sep 14, 2017 at 3:02 AM, Denis Mekhanikov <[hidden email]>
> wrote:
>
> > Dmitriy,
> >
> > You are right about transactions, but the spec describes invoke, so, if
> it
> > specifies some behavior in general, then it should be followed in both
> > cases.
> >
> > Here is the most relevant part I could find in the spec:
> > https://static.javadoc.io/javax.cache/cache-api/1.0.0/
> > javax/cache/processor/EntryProcessor.html
> > I think, that if the value is loaded from CacheStore, then
> > getExpiryForCreation() should be used. Other methods should be called
> > depending on operations performed.
> >
> > Denis
> >
> > чт, 14 сент. 2017 г. в 12:02, Denis Mekhanikov <[hidden email]>:
> >
> > > Val,
> > >
> > > Sorry, I may be didn't formulate the issue clearly. Other than
> predefined
> > > expiry policies (like CreatedExpiryPolicy, AccessedExpiryPolicy, etc)
> you
> > > can provide a custom expiry policy by calling
> > > setExpiryPolicyFactory(Factory<ExpiryPolicy>)
> > > <https://ignite.apache.org/releases/latest/javadoc/org/
> > apache/ignite/configuration/CacheConfiguration.html#
> > setExpiryPolicyFactory(javax.cache.configuration.Factory)>.
> > > So, cache will consult the configured ExpiryPolicy by calling
> > > getExpiryForCreation(), getExpiryForAccess() or getExpiryForUpdate(),
> > > depending on the performed operation.
> > >
> > > So, the methods of ExpiryPolicy that are called when invoke(...)
> > > <https://ignite.apache.org/releases/latest/javadoc/org/
> > apache/ignite/IgniteCache.html#invoke(K,%20org.apache.ignite.cache.
> > CacheEntryProcessor,%20java.lang.Object...)> is
> > > used, somehow depend on the configured atomicity. Of course, the
> > configured
> > > ExpiryPolicy is used, but in some cases the wrong method is called.
> > >
> > > Denis
> > >
> > > чт, 14 сент. 2017 г. в 1:54, Valentin Kulichenko <
> > > [hidden email]>:
> > >
> > >> Denis,
> > >>
> > >> I'm confused by the issue. Do you mean that we can use expiry policy
> > other
> > >> than the one provided in configuration? How is this possible? Can you
> > >> point
> > >> to the code that implements this logic?
> > >>
> > >> -Val
> > >>
> > >> On Wed, Sep 13, 2017 at 11:29 AM, Dmitriy Setrakyan <
> > >> [hidden email]>
> > >> wrote:
> > >>
> > >> > Denis,
> > >> >
> > >> > I agree that the behavior should be consistent, but you will not
> find
> > >> > anything about transactions in JCache. To my knowledge, JCache does
> > not
> > >> > have transactions.
> > >> >
> > >> > I would file a ticket about the issue you found, so the community
> > could
> > >> > address it. If you are interested, perhaps you can contribute a fix
> > >> > yourself.
> > >> >
> > >> > Thanks,
> > >> > D.
> > >> >
> > >> > On Wed, Sep 13, 2017 at 5:47 AM, Denis Mekhanikov <
> > >> [hidden email]>
> > >> > wrote:
> > >> >
> > >> > > Igniters!
> > >> > >
> > >> > > I noticed a weird behavior regarding expiry policy in Ignite. You
> > can
> > >> > find
> > >> > > an example in the attachment.
> > >> > > When you call invoke on a cache with configured CacheStore and
> > >> > > ExpiryPolicy, then chosen expiry depends on cache's atomicity
> mode.
> > >> > > If cache is atomic, then "creation" expiry timeout is chosen, but
> if
> > >> it
> > >> > is
> > >> > > transactional - then "access".
> > >> > >
> > >> > > I think, this behavior should at least be identical in both cases,
> > but
> > >> > > what is more important, it should conform to JCache specification.
> > >> > > But I wasn't able to find a clear statement regarding this
> question
> > in
> > >> > the
> > >> > > specification. Can somebody point out a place in the specification
> > >> that
> > >> > > defines a behavior in such case?
> > >> > >
> > >> > > Cheers,
> > >> > > Denis
> > >> > >
> > >> >
> > >>
> > >
> >
>