Re: [infinispan-dev] not sure if this is the place to post a question on infinispan

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

Re: [infinispan-dev] not sure if this is the place to post a question on infinispan

Wayne Wang
Hi All,

I am not sure if this is the place I could post a question on infinispan.

Basically, I am testing a scenario of invalidation cache in a cluster environment. It looks like the instance that actually modified the object has not problem of re-building the cache after data is updated, but the instances (in the same cluster) receiving the signal to invalidate the cache will indeed invalidate the cache, but can not re-build the cache until cache expiration.

Is this intended design, or there is some wrong in the configuration?

Thanks,

Wayne

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Sanne Grinovero
Sent: Monday, July 31, 2017 12:04 PM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Conflict Manager and Partition Handling Blog

Great job! I love to see this improved and being described in detail.

+1 to add some practical examples, as I'm afraid we only notice
limitations in features like this when thinking about specific use-cases.

The option `REMOVE_ALL` seems sensible for the disposable Cache use case. One question though: if one partition has a defined value for a key, while the other partition has no value (null) for this same key, is it considered a conflict?
I think you need to clarify if a "null" in a subset of partitions causes the conflict merge to be triggered or not. I think it should:
for example having the cache use case in mind, an explicit invalidation needs to be propagated safely.

Thanks,
Sanne


On 26 July 2017 at 13:41, Ryan Emerson <[hidden email]> wrote:

> Hi Galder,
>
> Thanks for the feedback.
>
> Conflicts are detected by applying a predicate to the returned
> Map<Address, CacheEntry> for each cache entry. Currently this
> predicate utilises Stream::distinct (so .equals), to check for
> multiple versions of an entry. So implementing pluggable strategies
> for defining a conflict should be trivial :)
>
> Good idea about a simple tutorial/demo, I'll look into it when I get a chance.
>
> Cheers
> Ryan
>
> ----- Original Message -----
>> Oh, if we can't find a simple tutorial for it, there's always
>> https://github.com/infinispan-demos :)
>>
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>> > On 25 Jul 2017, at 17:11, Galder Zamarreño <[hidden email]> wrote:
>> >
>> > One more thing: have you thought how we could have a simple
>> > tutorial on this feature?
>> >
>> > It'd be great to find a simple, reduced, example to show it off :)
>> >
>> > Cheers,
>> > --
>> > Galder Zamarreño
>> > Infinispan, Red Hat
>> >
>> >> On 25 Jul 2017, at 16:54, Galder Zamarreño <[hidden email]> wrote:
>> >>
>> >> Hey Ryan,
>> >>
>> >> Very detailed blog post! Great work on both the post and the
>> >> feature! :D
>> >>
>> >> While reading, the following question came to my mind: how does
>> >> Infinispan determine there's a conflict? Does it rely on .equals() based equality?
>> >>
>> >> A follow up would be: whether in the future this could be pluggable, e.g.
>> >> when comparing a version field is enough to realise there's a conflict.
>> >> As opposed of relying in .equals(), if that's what's being used
>> >> inside :)
>> >>
>> >> Cheers,
>> >> --
>> >> Galder Zamarreño
>> >> Infinispan, Red Hat
>> >>
>> >>> On 17 Jul 2017, at 14:16, Ryan Emerson <[hidden email]> wrote:
>> >>>
>> >>> Hi Everyone,
>> >>>
>> >>> Here's a blog post on the introduction of ConflictManager and the
>> >>> recent changes to partition handling.
>> >>>
>> >>> http://blog.infinispan.org/2017/07/conflict-management-and-partit
>> >>> ion.html
>> >>>
>> >>> Cheers
>> >>> Ryan
>> >>> _______________________________________________
>> >>> 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

_______________________________________________
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] not sure if this is the place to post a question on infinispan

Radim Vansa
Hi Wayne,

the proper place to ask for help are the forums [1], this mailing list
is rather for discussing of development (as the -dev suggests).

I am not sure if I understand your question, though; what do you mean by
re-building the cache? In invalidation mode, one node inserts the data
into cache and others wipe the (out-of-date) entry out. The nodes don't
try to fetch the data from anywhere, this should be done by application
which does not find the data in cache and therefore loads it from
external source and then caches it using
cache.withFlags(Flag.PUT_FROM_EXTERNAL_READ).put(...). This flag causes
the node to not invalidate remote nodes (as the regular put which
inserts "updated" data).

Since you reply on the Conflict-Manager thread, is your question anyhow
related to partition handling? (afaik this is not supported in
invalidation caches).

Radim

[1]
https://developer.jboss.org/en/infinispan/content?filterID=contentstatus%5Bpublished%5D~objecttype~objecttype%5Bthread%5D

On 07/31/2017 10:31 PM, Wayne Wang wrote:

> Hi All,
>
> I am not sure if this is the place I could post a question on infinispan.
>
> Basically, I am testing a scenario of invalidation cache in a cluster environment. It looks like the instance that actually modified the object has not problem of re-building the cache after data is updated, but the instances (in the same cluster) receiving the signal to invalidate the cache will indeed invalidate the cache, but can not re-build the cache until cache expiration.
>
> Is this intended design, or there is some wrong in the configuration?
>
> Thanks,
>
> Wayne
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Sanne Grinovero
> Sent: Monday, July 31, 2017 12:04 PM
> To: infinispan -Dev List
> Subject: Re: [infinispan-dev] Conflict Manager and Partition Handling Blog
>
> Great job! I love to see this improved and being described in detail.
>
> +1 to add some practical examples, as I'm afraid we only notice
> limitations in features like this when thinking about specific use-cases.
>
> The option `REMOVE_ALL` seems sensible for the disposable Cache use case. One question though: if one partition has a defined value for a key, while the other partition has no value (null) for this same key, is it considered a conflict?
> I think you need to clarify if a "null" in a subset of partitions causes the conflict merge to be triggered or not. I think it should:
> for example having the cache use case in mind, an explicit invalidation needs to be propagated safely.
>
> Thanks,
> Sanne
>
>
> On 26 July 2017 at 13:41, Ryan Emerson <[hidden email]> wrote:
>> Hi Galder,
>>
>> Thanks for the feedback.
>>
>> Conflicts are detected by applying a predicate to the returned
>> Map<Address, CacheEntry> for each cache entry. Currently this
>> predicate utilises Stream::distinct (so .equals), to check for
>> multiple versions of an entry. So implementing pluggable strategies
>> for defining a conflict should be trivial :)
>>
>> Good idea about a simple tutorial/demo, I'll look into it when I get a chance.
>>
>> Cheers
>> Ryan
>>
>> ----- Original Message -----
>>> Oh, if we can't find a simple tutorial for it, there's always
>>> https://github.com/infinispan-demos :)
>>>
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 25 Jul 2017, at 17:11, Galder Zamarreño <[hidden email]> wrote:
>>>>
>>>> One more thing: have you thought how we could have a simple
>>>> tutorial on this feature?
>>>>
>>>> It'd be great to find a simple, reduced, example to show it off :)
>>>>
>>>> Cheers,
>>>> --
>>>> Galder Zamarreño
>>>> Infinispan, Red Hat
>>>>
>>>>> On 25 Jul 2017, at 16:54, Galder Zamarreño <[hidden email]> wrote:
>>>>>
>>>>> Hey Ryan,
>>>>>
>>>>> Very detailed blog post! Great work on both the post and the
>>>>> feature! :D
>>>>>
>>>>> While reading, the following question came to my mind: how does
>>>>> Infinispan determine there's a conflict? Does it rely on .equals() based equality?
>>>>>
>>>>> A follow up would be: whether in the future this could be pluggable, e.g.
>>>>> when comparing a version field is enough to realise there's a conflict.
>>>>> As opposed of relying in .equals(), if that's what's being used
>>>>> inside :)
>>>>>
>>>>> Cheers,
>>>>> --
>>>>> Galder Zamarreño
>>>>> Infinispan, Red Hat
>>>>>
>>>>>> On 17 Jul 2017, at 14:16, Ryan Emerson <[hidden email]> wrote:
>>>>>>
>>>>>> Hi Everyone,
>>>>>>
>>>>>> Here's a blog post on the introduction of ConflictManager and the
>>>>>> recent changes to partition handling.
>>>>>>
>>>>>> http://blog.infinispan.org/2017/07/conflict-management-and-partit
>>>>>> ion.html
>>>>>>
>>>>>> Cheers
>>>>>> Ryan
>>>>>> _______________________________________________
>>>>>> 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
> _______________________________________________
> 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
Loading...