[infinispan-dev] design for cluster events (wiki page)

[Mircea Markus]

> On 31 Oct 2013, at 08:31, Radim Vansa <rvansa at redhat.com> wrote:
> 
>> On 10/31/2013 08:10 AM, Bela Ban wrote:
>> Just to clarify, can you comment on whether the statements below are true ?
>> 
>> #1 When mode=repl is used, the event itself is never broadcast; it is
>> always local and no communication is needed
> Related to that - is the filter always applied only on primary owner? If 
> the registering node is backup owner, it could omit the communication as 
> well.
 I think it would make sense to be on the main owner, yes. Another option would be to have it on writing node, but then if some nods write more than the other, the filtering effort won't be spread evenly.
>> 
>> #2 when mode=dist, is the event broadcast synchronously or
>> asynchronously, can this be configured ? I think it doesn't make sense
>> to broadcast the event synchronously in dist-async, for instance.
> +1 The sync/async nature of the events should be configurable, and 
> behaviour with async cache clearly stated.
>> 
>> Regarding #2: if this mechanism is used unwisely, a user can destroy all
>> the advantages (perf) brought by DIST by causing a broadcast for every
>> update. Is there anything to prevent this (e.g. a sanity check at startup) ?
> One of advantages of distributed mode is the memory requirement - this 
> wouldn't be destroyed, but sure, the cluster wouldn't scale anymore.
> Nevertheless I think that the filter is sufficient prevention (maybe the 
> API shouldn't allow null filter as "accept all" solution, because that 
> would lead to exactly this situation).
> 
> Btw., do we expect two events for each modification (pre/post),

I think it should, for consistency.
I somehow don't like the pre/post methods on the Event, might be nicer to move them as an attribute to the listener itself. 

> or only 
> single one? If the listener throws an exception is this propagated to 
> the node where the write originates?

I don't think the filter should propagate/veto operation, at least in the first phase. Definitely something to document though.

> 
> One more thing not clearly stated on the wiki: the order is probably 
> guaranteed only with respect to one entry - ordering within multiple 
> writes (for example within the same transaction) is not guaranteed.

Indeed.

> 
> Radim
>> 
>>> On 10/30/13 8:33 PM, Mircea Markus wrote:
>>> Okay, and now the good URL (3rd try): https://github.com/infinispan/infinispan/wiki/Clustered-listeners
>>> 
>>>> On Oct 30, 2013, at 7:31 PM, Mircea Markus <mmarkus at redhat.com> wrote:
>>>> 
>>>> Ups, wrong URL.
>>>> 
>>>> This is the  design for  cluster events: https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions
>>>> 
>>>> 
>>>>> On Oct 30, 2013, at 7:05 PM, Mircea Markus <mmarkus at redhat.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I've added a wiki page[1] capturing our discussions around cluster events.
>>>>> Any feedback welcomed!
>>>>> 
>>>>> [1] https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions
>>>>> 
>>>>> Cheers,
>>>>> --
>>>>> Mircea Markus
>>>>> Infinispan lead (www.infinispan.org)
>>>> Cheers,
>>>> --
>>>> Mircea Markus
>>>> Infinispan lead (www.infinispan.org)
>>> Cheers,
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev