ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Николай Ижиков <nizhikov....@gmail.com>
Subject Re: ContinuousQueryWithTransformer implementation questions - 2
Date Mon, 04 Sep 2017 11:05:36 GMT
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