On 31 Oct 2013, at 08:31, Radim Vansa <rvansa(a)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(a)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(a)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(a)redhat.com>
JBoss DataGrid QA
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev