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&gt; 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&gt; 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&gt; 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&gt; 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