ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Vinogradov <avinogra...@gridgain.com>
Subject Re: Add new event in putblic API
Date Tue, 08 Nov 2016 07:29:28 GMT
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