[infinispan-dev] not sure if this is the place to post a question on infinispan

[Radim Vansa]

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


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team