You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Denis Mekhanikov <dm...@gmail.com> on 2017/09/13 12:47:48 UTC
Expiry policy for Cache.invoke
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
Re: Expiry policy for Cache.invoke
Posted by Denis Mekhanikov <dm...@gmail.com>.
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 <
valentin.kulichenko@gmail.com>:
> 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 <dm...@gmail.com>
> 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 <dm...@gmail.com>:
> >
> > > 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 <
> > > valentin.kulichenko@gmail.com>:
> > >
> > >> 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 <
> > >> dsetrakyan@apache.org>
> > >> 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 <
> > >> dmekhanikov@gmail.com>
> > >> > 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
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: Expiry policy for Cache.invoke
Posted by Valentin Kulichenko <va...@gmail.com>.
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 <dm...@gmail.com>
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 <dm...@gmail.com>:
>
> > 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 <
> > valentin.kulichenko@gmail.com>:
> >
> >> 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 <
> >> dsetrakyan@apache.org>
> >> 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 <
> >> dmekhanikov@gmail.com>
> >> > 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
> >> > >
> >> >
> >>
> >
>
Re: Expiry policy for Cache.invoke
Posted by Denis Mekhanikov <dm...@gmail.com>.
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 <dm...@gmail.com>:
> 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 <
> valentin.kulichenko@gmail.com>:
>
>> 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 <
>> dsetrakyan@apache.org>
>> 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 <
>> dmekhanikov@gmail.com>
>> > 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
>> > >
>> >
>>
>
Re: Expiry policy for Cache.invoke
Posted by Denis Mekhanikov <dm...@gmail.com>.
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 <
valentin.kulichenko@gmail.com>:
> 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 <dsetrakyan@apache.org
> >
> 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 <dmekhanikov@gmail.com
> >
> > 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
> > >
> >
>
Re: Expiry policy for Cache.invoke
Posted by Valentin Kulichenko <va...@gmail.com>.
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 <ds...@apache.org>
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 <dm...@gmail.com>
> 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
> >
>
Re: Expiry policy for Cache.invoke
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <dm...@gmail.com>
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
>