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]
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: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] 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 <remerson(a)redhat.com> 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 <galder(a)redhat.com> 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 <galder(a)redhat.com>
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 <remerson(a)redhat.com>
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
>>>>> infinispan-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev