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-boun...@lists.jboss.org [mailto:infinispan-dev-boun...@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 <remer...@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 <gal...@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 <gal...@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 <remer...@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@lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> > >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev