ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Vinogradov ...@apache.org>
Subject Re: ContinuousQueryWithTransformer implementation questions - 2
Date Mon, 04 Sep 2017 11:20:57 GMT
+1 to keep current behavior and start new thread to solve notification
issue.

On Mon, Sep 4, 2017 at 2:05 PM, Николай Ижиков <nizhikov.dev@gmail.com>
wrote:

> Hello, Yakov.
>
> I made a bit of investigation about your proposal of handling filter and
> transformer exceptions:
>
> 1. If we cancel continuous query from remote node user can't know it.
>     There is no public API to check "Is continuous query still alive?".
>     The only consequence of canceling query - listener not called on a
> local node.
>
> 2. If we change a behavior of filter exception handling then we broke
> backward compatibility. Is it OK?
>
> 3. If we implement query cancel only for transformer exception - behavior
> would be different for filter and transformer.
>
> I think changes for consistent exception handling requires additional
> discussion.
> I will start such discussion in another thread but seems that it not
> related to current issue as it also touches current ContinuousQuery
> implementation.
>
> Can we stay with current behavior for current task(IGNITE-425)?
>
> * filter exception treats as true
> * transformer exception treats as null
>
>
> 2017-08-30 17:16 GMT+03:00 Yakov Zhdanov <yzhdanov@gridgain.com>:
>
> > I would postpone review until we come to a clear decision on what should
> be
> > done if filter or transformer fails. I don't think cancelling query is
> too
> > much. From my standpoint this is a kind of heuristic exception and may
> > break some sensitive logic.
> >
> > Thanks!
> > --
> > Yakov Zhdanov, Director R&D
> > *GridGain Systems*
> > www.gridgain.com
> >
> > 2017-08-30 16:24 GMT+03:00 Nikolay Izhikov <nizhikov.dev@gmail.com>:
> >
> > > Hello, Yakov.
> > >
> > > The new class is OK - got it. Thanks!
> > >
> > > > Should we extract a super class?
> > >
> > > Yes, we should.
> > > I already have done it.
> > >
> > > See my last commit in PR - https://github.com/apache/igni
> > > te/pull/2372/commits/af1ed2e4dbef4ba5999f8566198cb75ad922f93b
> > >
> > > > We can put hard requirement that filter and transformer cannot throw
> > > > exception (same as cache interceptor).
> > >
> > > I think to cancel the whole query on transformer exception is too much.
> > > After discussion, I like the idea to skip event if transformer throws
> > > exception. As far as it "like regular filter" behavior.
> > >
> > > Thoughts?
> > >
> > >
> > > 30.08.2017 16:03, Yakov Zhdanov пишет:
> > >
> > > I think I have already agreed on a separate class since it seems to be
> > the
> > >> only option due to generics issue. Should we extract a super class?
> > >>
> > >> We can put hard requirement that filter and transformer cannot throw
> > >> exception (same as cache interceptor). If exception is thrown then we
> > >> cancel the query globally and unregister all the listeners. This may
> > sound
> > >> too much but inconsistencies brought by listener notifications may be
> > >> terrible for app.
> > >>
> > >> --Yakov
> > >>
> > >>
> >
>
>
>
> --
> Nikolay Izhikov
> NIzhikov.dev@gmail.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message