Pavel, this is source node ID which is already in the event, as you
mentioned. Vladimir, can you please file a ticket?

--Yakov

2015-10-13 14:11 GMT+03:00 Pavel Tupitsyn <ptupit...@gridgain.com>:

> Related question:
>
> What does first UUID arg mean in "IgniteBiPredicate<UUID, T> locLsnr"?
> It can either be event source node id, which is already included in Event
> interface, or local node id, which does not make much sense.
>
> On Tue, Oct 13, 2015 at 1:57 PM, Vladimir Ozerov <voze...@gridgain.com>
> wrote:
>
> > Igniters,
> >
> > I was looking at IgniteEvents.remoteListen() and failed to understand how
> > it works. Can someone explain me semantics please?
> >
> > 1) What is the point of *local* listener in the method "*remote*Listen"?
> > Are we collecting events remotely and send them to the local node? If
> yes,
> > then this is not "remoteListen", it is "localListen" with additional
> remote
> > filters.
> >
> > 2) How does "IgnitePredicate<T> rmtFilter" argument work? JavaDoc says:
> > "It will be auto-unsubsribed on the node where event occurred in case if
> it
> > returns {@code false}."
> > Is this a filter that stops working when "false" is returned? If yes,
> this
> > is not a filter, I am afraid. It doesn't filter anything. This is
> something
> > else I cannot name.
> >
> > To the contrast please look at IgniteMessaging.remoteListen() - clean and
> > consistent method.
> >
> > Looks like we need to rethink this API. The closest concept is continuous
> > queries. It has a remote filter (which is really a filter) and a local
> > listener.
> >
> > I would remove/deprecate "remoteListen" method and do something like
> this:
> >
> > UUID listen(IgniteInClosure<Event> locLsnr, @Nullable
> > IgnitePredicate<Event> rmtFilter, bool autoUnsubscribe);
> > bool stopListen(UUID id);
> >
> > Thoughts?
> >
>
>
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
>

Reply via email to