Quantcast

[infinispan-dev] SKIP_CACHE_LOAD and write skew check

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] SKIP_CACHE_LOAD and write skew check

Radim Vansa
I've noticed that SKIP_CACHE_LOAD flag is ignored when performing the
write skew check (the old entry is loaded from cache store), though, it
is not ignored (and the entry is not loaded) when there's
CACHE_MODE_LOCAL [2]. Is that intended behaviour, or just "conserved" by
tests?

The flag itself allows to break things [3], so I guess that user sets
the flag only when he knows that there is no such entry in cache store
and it's safe to not load it.

Moreover, I don't understand why the WSC should be performed on
originator (or backup owners) [4].

Thanks for explanations (I'll try to add them as comments to the code -
or make the reasoning more obvious).

Radim

[1]
https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L132
[2]
https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L96
[3]
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/context/Flag.java#L89
[4]
https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L85


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] SKIP_CACHE_LOAD and write skew check

Sanne Grinovero-3
I'm not sure why this specific Flag behaves like this, but it's clear
that Flags can break many things; I suspect originally they were meant
to be internal-only, and I got them exposed when as a user I was
having big performance trouble when doing Put operations of 1GB each
and the damn thing would load the previous value from the MySQL backed
Cachestore, while my puts didn't use the return value :)

Maybe it's time to reconsider this and split the flags up in "internal
ones" and public API flags? It would be nice to limit the damage that
end users can do, many flags could be taken away, or reshape our APIs
to not really need so many (for example not having the put method
return a value, or automating such optimisations with internal magic).

+1 to perform the WSC only on the primary owner, that seems like a severe bug?


On 30 August 2016 at 08:30, Radim Vansa <[hidden email]> wrote:

> I've noticed that SKIP_CACHE_LOAD flag is ignored when performing the
> write skew check (the old entry is loaded from cache store), though, it
> is not ignored (and the entry is not loaded) when there's
> CACHE_MODE_LOCAL [2]. Is that intended behaviour, or just "conserved" by
> tests?
>
> The flag itself allows to break things [3], so I guess that user sets
> the flag only when he knows that there is no such entry in cache store
> and it's safe to not load it.
>
> Moreover, I don't understand why the WSC should be performed on
> originator (or backup owners) [4].
>
> Thanks for explanations (I'll try to add them as comments to the code -
> or make the reasoning more obvious).
>
> Radim
>
> [1]
> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L132
> [2]
> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L96
> [3]
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/context/Flag.java#L89
> [4]
> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L85
>
>
> --
> Radim Vansa <[hidden email]>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] SKIP_CACHE_LOAD and write skew check

Pedro Ruivo-2
The WSC is only performed on the primary owner. But the originator needs
to keep track of the version read in order to the WSC be performed.

I've changed this behavior for IGNORE_RETURN_VALUE flags, where the
entry is mark as "not-read" (if it wasn't read before). Then, the WSC is
skipped for this entry.

I probably should have done the same thing for SKIP_CACHE_LOAD.

CACHE_MODE_LOCAL is other flag that, IMO, shouldn't be supported by
Transactional Caches.

I agree with Sanne and we should re-check all flags since most of them
can hurt the data consistency.

On 30-08-2016 11:06, Sanne Grinovero wrote:

> I'm not sure why this specific Flag behaves like this, but it's clear
> that Flags can break many things; I suspect originally they were meant
> to be internal-only, and I got them exposed when as a user I was
> having big performance trouble when doing Put operations of 1GB each
> and the damn thing would load the previous value from the MySQL backed
> Cachestore, while my puts didn't use the return value :)
>
> Maybe it's time to reconsider this and split the flags up in "internal
> ones" and public API flags? It would be nice to limit the damage that
> end users can do, many flags could be taken away, or reshape our APIs
> to not really need so many (for example not having the put method
> return a value, or automating such optimisations with internal magic).
>
> +1 to perform the WSC only on the primary owner, that seems like a severe bug?
>
>
> On 30 August 2016 at 08:30, Radim Vansa <[hidden email]> wrote:
>> I've noticed that SKIP_CACHE_LOAD flag is ignored when performing the
>> write skew check (the old entry is loaded from cache store), though, it
>> is not ignored (and the entry is not loaded) when there's
>> CACHE_MODE_LOCAL [2]. Is that intended behaviour, or just "conserved" by
>> tests?
>>
>> The flag itself allows to break things [3], so I guess that user sets
>> the flag only when he knows that there is no such entry in cache store
>> and it's safe to not load it.
>>
>> Moreover, I don't understand why the WSC should be performed on
>> originator (or backup owners) [4].
>>
>> Thanks for explanations (I'll try to add them as comments to the code -
>> or make the reasoning more obvious).
>>
>> Radim
>>
>> [1]
>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L132
>> [2]
>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L96
>> [3]
>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/context/Flag.java#L89
>> [4]
>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L85
>>
>>
>> --
>> Radim Vansa <[hidden email]>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] SKIP_CACHE_LOAD and write skew check

Radim Vansa
On 08/30/2016 12:52 PM, Pedro Ruivo wrote:

> The WSC is only performed on the primary owner. But the originator needs
> to keep track of the version read in order to the WSC be performed.
>
> I've changed this behavior for IGNORE_RETURN_VALUE flags, where the
> entry is mark as "not-read" (if it wasn't read before). Then, the WSC is
> skipped for this entry.
>
> I probably should have done the same thing for SKIP_CACHE_LOAD.
>
> CACHE_MODE_LOCAL is other flag that, IMO, shouldn't be supported by
> Transactional Caches.
>
> I agree with Sanne and we should re-check all flags since most of them
> can hurt the data consistency.

I think there are valid use cases for skipping the cache load, and it's
hidden well enough that users won't use that just accidentally. But I
don't see any opinions if the WSC should honor or ignore this flag (I
would honor it).

Radim

>
> On 30-08-2016 11:06, Sanne Grinovero wrote:
>> I'm not sure why this specific Flag behaves like this, but it's clear
>> that Flags can break many things; I suspect originally they were meant
>> to be internal-only, and I got them exposed when as a user I was
>> having big performance trouble when doing Put operations of 1GB each
>> and the damn thing would load the previous value from the MySQL backed
>> Cachestore, while my puts didn't use the return value :)
>>
>> Maybe it's time to reconsider this and split the flags up in "internal
>> ones" and public API flags? It would be nice to limit the damage that
>> end users can do, many flags could be taken away, or reshape our APIs
>> to not really need so many (for example not having the put method
>> return a value, or automating such optimisations with internal magic).
>>
>> +1 to perform the WSC only on the primary owner, that seems like a severe bug?
>>
>>
>> On 30 August 2016 at 08:30, Radim Vansa <[hidden email]> wrote:
>>> I've noticed that SKIP_CACHE_LOAD flag is ignored when performing the
>>> write skew check (the old entry is loaded from cache store), though, it
>>> is not ignored (and the entry is not loaded) when there's
>>> CACHE_MODE_LOCAL [2]. Is that intended behaviour, or just "conserved" by
>>> tests?
>>>
>>> The flag itself allows to break things [3], so I guess that user sets
>>> the flag only when he knows that there is no such entry in cache store
>>> and it's safe to not load it.
>>>
>>> Moreover, I don't understand why the WSC should be performed on
>>> originator (or backup owners) [4].
>>>
>>> Thanks for explanations (I'll try to add them as comments to the code -
>>> or make the reasoning more obvious).
>>>
>>> Radim
>>>
>>> [1]
>>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L132
>>> [2]
>>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L96
>>> [3]
>>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/context/Flag.java#L89
>>> [4]
>>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L85
>>>
>>>
>>> --
>>> Radim Vansa <[hidden email]>
>>> JBoss Performance Team
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] SKIP_CACHE_LOAD and write skew check

Dan Berindei
+1 to honor it. I should have done it back when I did ISPN-5643 [1],
but I guess I was afraid about breaking more tests.

Note that before ISPN-5643 conditional writes also used to ignore
SKIP_CACHE_LOAD, and the javadoc encouraged users to enable it
together with SKIP_REMOTE_LOOKUP.

[1]: https://issues.jboss.org/browse/ISPN-5643

Cheers
Dan


On Tue, Aug 30, 2016 at 1:59 PM, Radim Vansa <[hidden email]> wrote:

> On 08/30/2016 12:52 PM, Pedro Ruivo wrote:
>> The WSC is only performed on the primary owner. But the originator needs
>> to keep track of the version read in order to the WSC be performed.
>>
>> I've changed this behavior for IGNORE_RETURN_VALUE flags, where the
>> entry is mark as "not-read" (if it wasn't read before). Then, the WSC is
>> skipped for this entry.
>>
>> I probably should have done the same thing for SKIP_CACHE_LOAD.
>>
>> CACHE_MODE_LOCAL is other flag that, IMO, shouldn't be supported by
>> Transactional Caches.
>>
>> I agree with Sanne and we should re-check all flags since most of them
>> can hurt the data consistency.
>
> I think there are valid use cases for skipping the cache load, and it's
> hidden well enough that users won't use that just accidentally. But I
> don't see any opinions if the WSC should honor or ignore this flag (I
> would honor it).
>
> Radim
>
>>
>> On 30-08-2016 11:06, Sanne Grinovero wrote:
>>> I'm not sure why this specific Flag behaves like this, but it's clear
>>> that Flags can break many things; I suspect originally they were meant
>>> to be internal-only, and I got them exposed when as a user I was
>>> having big performance trouble when doing Put operations of 1GB each
>>> and the damn thing would load the previous value from the MySQL backed
>>> Cachestore, while my puts didn't use the return value :)
>>>
>>> Maybe it's time to reconsider this and split the flags up in "internal
>>> ones" and public API flags? It would be nice to limit the damage that
>>> end users can do, many flags could be taken away, or reshape our APIs
>>> to not really need so many (for example not having the put method
>>> return a value, or automating such optimisations with internal magic).
>>>
>>> +1 to perform the WSC only on the primary owner, that seems like a severe bug?
>>>
>>>
>>> On 30 August 2016 at 08:30, Radim Vansa <[hidden email]> wrote:
>>>> I've noticed that SKIP_CACHE_LOAD flag is ignored when performing the
>>>> write skew check (the old entry is loaded from cache store), though, it
>>>> is not ignored (and the entry is not loaded) when there's
>>>> CACHE_MODE_LOCAL [2]. Is that intended behaviour, or just "conserved" by
>>>> tests?
>>>>
>>>> The flag itself allows to break things [3], so I guess that user sets
>>>> the flag only when he knows that there is no such entry in cache store
>>>> and it's safe to not load it.
>>>>
>>>> Moreover, I don't understand why the WSC should be performed on
>>>> originator (or backup owners) [4].
>>>>
>>>> Thanks for explanations (I'll try to add them as comments to the code -
>>>> or make the reasoning more obvious).
>>>>
>>>> Radim
>>>>
>>>> [1]
>>>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L132
>>>> [2]
>>>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L96
>>>> [3]
>>>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/context/Flag.java#L89
>>>> [4]
>>>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L85
>>>>
>>>>
>>>> --
>>>> Radim Vansa <[hidden email]>
>>>> JBoss Performance Team
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <[hidden email]>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...