On 10/31/13 1:05 PM, Mircea Markus wrote: > > On Oct 31, 2013, at 7:10 AM, Bela Ban <[email protected]> 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 > > yes. for replicated caches we should handle this as a local listener. > >> >> #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. > > there are two levels of asynchronicity: > - the cluster is configured to be asyn > - the listeners can be configured to be notified in an async thread > (@Listener async=true) > In both situations the notification from the event should be broadcasted > asynchronously
Ah, ok, so the events are *always* async ? +1 in general, but there's a point where you mentioned ordering, and ordering might get destroyed if you switch to async. >> 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) ? > > I guess we should expose a "filtering rate" statistics on every filter and > log INFO if the filtering rate is very low. That should at least give an idea > on the amount of traffic caused by the listener. > > Thank you Bela, I'll update the doc with your suggestions. > > > Cheers, > -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
