On 10/31/13 1:05 PM, Mircea Markus wrote:
On Oct 31, 2013, at 7:10 AM, Bela Ban <bban(a)redhat.com> 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)