ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: Add new event in putblic API
Date Tue, 08 Nov 2016 07:32:04 GMT
I would better add onError() to CQ local listener.

--Yakov

2016-11-08 10:29 GMT+03:00 Anton Vinogradov <avinogradov@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 <vozerov@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 <
> > avinogradov@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 <
> dsetrakyan@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 <av@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 <
> > > dsetrakyan@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.govorukhin@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>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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