+1 to keep current behavior and start new thread to solve notification issue.
On Mon, Sep 4, 2017 at 2:05 PM, Николай Ижиков <nizhikov....@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 <yzhda...@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....@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....@gmail.com >
