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