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: 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 -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
