3:31 p.m.
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