This will break compatibility with user code in case this method will not be optional.
On Tue, Nov 8, 2016 at 10:32 AM, Yakov Zhdanov <yzhda...@apache.org> wrote: > I would better add onError() to CQ local listener. > > --Yakov > > 2016-11-08 10:29 GMT+03:00 Anton Vinogradov <avinogra...@gridgain.com>: > > > Vova, > > > > We just give user 2 additional tips. > > We write exception to ExceptionRegistry and send event. > > In case user will use some management console he will see big red warning > > window. > > > > > > On Tue, Nov 8, 2016 at 10:22 AM, Vladimir Ozerov <voze...@gridgain.com> > > wrote: > > > > > I am not quite sure how user is going to use it. Could you please > provide > > > pseudocode for that? In particular, I do not understand how user will > > > understand the source of this exception, and how will he match > exception > > > event with particular CQ listener. > > > > > > On Tue, Nov 8, 2016 at 10:18 AM, Anton Vinogradov < > > > avinogra...@gridgain.com> > > > wrote: > > > > > > > UnhandledExceptionEvent will be used for notification. > > > > > > > > Current code will just write error to log, > > > > new code will write error to log, write it to the ExceptionRegistry > and > > > > inform user using UnhandledExceptionEvent > > > > > > > > On Tue, Nov 8, 2016 at 1:41 AM, Dmitriy Setrakyan < > > dsetrak...@apache.org > > > > > > > > wrote: > > > > > > > > > I think I am missing something. If you are saying that we have no > way > > > to > > > > > notify CQ listeners if the notification message failed, how do you > > plan > > > > to > > > > > notify them about the failure? What if the failure message also > > fails? > > > > > > > > > > On Sun, Nov 6, 2016 at 11:45 PM, Anton Vinogradov <a...@apache.org> > > > wrote: > > > > > > > > > > > Dmitriy, > > > > > > > > > > > > In cases where ContinuousQuery Event unmarshalling failed we have > > to > > > > > inform > > > > > > node's owner somehow. > > > > > > Failed CQ event means you'll just get no event, no exception, and > > > > you'll > > > > > > have no need to read logs. > > > > > > Currently, we have no possibility to inform user except writing > > error > > > > > > message to logs. > > > > > > > > > > > > So, we have two ways to inform user: 1) to extend CQ API with new > > > > method > > > > > > listentFailedEvents() 2) or to let user listen for > > > > > UnhandledExceptionEvent > > > > > > First case will break old sources using Ignite CQ in case method > > will > > > > be > > > > > > required, and gives no profit in case it will be optional. > > > > > > Second case will allow to listen such events or/and to see them > at > > > some > > > > > > management tool (eg. Visor). > > > > > > > > > > > > So, current solution is to log such failures, write them to > > > > > > ExceptionRegistry and inform user using UnhandledExceptionEvent > > (via > > > > > > listener or management console). > > > > > > > > > > > > On Fri, Nov 4, 2016 at 6:34 AM, Dmitriy Setrakyan < > > > > dsetrak...@apache.org > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Dmitriy, I am not sure how a public even would help fixing > > internal > > > > > error > > > > > > > handling. Also, the ticket has too many comments which makes it > > > > > difficult > > > > > > > to understand. Any chance you could provide the final proposal > > > here? > > > > > > > > > > > > > > On Thu, Nov 3, 2016 at 8:01 AM, Dmitriy Govorukhin < > > > > > > > dmitriy.govoruk...@gmail.com> wrote: > > > > > > > > > > > > > > > HI all, I think what we need add new event for handling > > > > > > > > unhandled exception. We have some exception which not > handled, > > > new > > > > > > > > event (UnhandledExceptionEvent) can > > > > > > > > help know if was unhandled exception. Let's discuss. More > > details > > > > > about > > > > > > > > reason IGNITE-2079 <https://issues.apache.org/ > > > > > jira/browse/IGNITE-2079> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
