Add new event in putblic API

[Dmitriy Govorukhin]

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>

[dsetrakyan]

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 <
[hidden email]> 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>
>

[Anton Vinogradov-2]

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 <[hidden email]>
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 <
> [hidden email]> 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>
> >
>

[dsetrakyan]

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 <[hidden email]> 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 <[hidden email]>
> 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 <
> > [hidden email]> 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>
> > >
> >
>

[Anton Vinogradov]

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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]
> >
> > 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 <
> > > [hidden email]> 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>
> > > >
> > >
> >
>

[Vladimir Ozerov]

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 <[hidden email]>
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 <[hidden email]>
> 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 <[hidden email]> 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 <
> [hidden email]
> > >
> > > 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 <
> > > > [hidden email]> 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>
> > > > >
> > > >
> > >
> >
>

[Anton Vinogradov]

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 <[hidden email]>
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 <
> [hidden email]>
> 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 <[hidden email]
> >
> > 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 <[hidden email]>
> 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 <
> > [hidden email]
> > > >
> > > > 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 <
> > > > > [hidden email]> 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>
> > > > > >
> > > > >
> > > >
> > >
> >
>

[yzhdanov]

I would better add onError() to CQ local listener.

--Yakov

2016-11-08 10:29 GMT+03:00 Anton Vinogradov <[hidden email]>:

> 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 <[hidden email]>
> 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 <
> > [hidden email]>
> > 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 <
> [hidden email]
> > >
> > > 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 <[hidden email]>
> > 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 <
> > > [hidden email]
> > > > >
> > > > > 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 <
> > > > > > [hidden email]> 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>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Anton Vinogradov]

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 <[hidden email]> wrote:

> I would better add onError() to CQ local listener.
>
> --Yakov
>
> 2016-11-08 10:29 GMT+03:00 Anton Vinogradov <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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 <
> > > [hidden email]>
> > > 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 <
> > [hidden email]
> > > >
> > > > 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 <[hidden email]>
> > > 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 <
> > > > [hidden email]
> > > > > >
> > > > > > 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 <
> > > > > > > [hidden email]> 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>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Vladimir Ozerov]

We can add separate callback as CQ setter. Exception event doesn't look
very useful for user to me.

08 нояб. 2016 г. 10:39 пользователь "Anton Vinogradov" <
[hidden email]> написал:

> 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 <[hidden email]>
> wrote:
>
> > I would better add onError() to CQ local listener.
> >
> > --Yakov
> >
> > 2016-11-08 10:29 GMT+03:00 Anton Vinogradov <[hidden email]>:
> >
> > > 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 <[hidden email]
> >
> > > 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 <
> > > > [hidden email]>
> > > > 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 <
> > > [hidden email]
> > > > >
> > > > > 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 <[hidden email]
> >
> > > > 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 <
> > > > > [hidden email]
> > > > > > >
> > > > > > > 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 <
> > > > > > > > [hidden email]> 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>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Alexey Kuznetsov]

Just my opinion about UnhandledExceptionEvent

1) All events are disabled by default. So user will need to configure.
2) Events buffer is 10_000 by default and UnhandledExceptionEvent could be
evicted from buffer by other frequent events.
3) User should collect events periodically.

So from my point of view some kind of "onError" listener (as suggested by
Yakov) will be better.

On Tue, Nov 8, 2016 at 2:22 PM, Vladimir Ozerov <[hidden email]>
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 <
> [hidden email]>
> 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 <[hidden email]
> >
> > 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 <[hidden email]>
> 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 <
> > [hidden email]
> > > >
> > > > 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 <
> > > > > [hidden email]> 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>
> > > > > >
> > > > >
> > > >
> > >
> >
>

--
Alexey Kuznetsov