IgniteEvents.remoteListen() semantics

[Vladimir Ozerov]

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-3]

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 <[hidden email]>
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

[yzhdanov]

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 <[hidden email]>:

> 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 <[hidden email]>
> 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
>

[Vladimir Ozerov]

Yakov, I'm not sure whether there are any problems or not. This is why I
wanted to understand what was the initial idea behind remoteListen() API
before creating the ticket.

On Wed, Oct 14, 2015 at 4:37 PM, Yakov Zhdanov <[hidden email]> wrote:

> 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 <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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
> >
>

[Yakov Zhdanov-2]

It uses similar approach as continuous query - remoteFiltering and
localListener notification.

Thanks!
--
Yakov Zhdanov, Director R&D
*GridGain Systems*
www.gridgain.com

2015-10-14 16:45 GMT+03:00 Vladimir Ozerov <[hidden email]>:

> Yakov, I'm not sure whether there are any problems or not. This is why I
> wanted to understand what was the initial idea behind remoteListen() API
> before creating the ticket.
>
> On Wed, Oct 14, 2015 at 4:37 PM, Yakov Zhdanov <[hidden email]>
> wrote:
>
> > 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 <[hidden email]>:
> >
> > > 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 <[hidden email]
> >
> > > 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
> > >
> >
>