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 poin
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" <
avinogra...@gridgain.com> написал:
> This will break compatibility with user code in case this method will not
> be optional.
>
> On Tue, No
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 wrote:
> I would better add onError() to CQ local listener.
>
> --Yakov
>
> 2016-11-08 10:29 GMT+03:00 Anton Vinogradov :
>
> > Vova,
> >
> > We just give user 2
I would better add onError() to CQ local listener.
--Yakov
2016-11-08 10:29 GMT+03:00 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
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
wrote:
> I am not quite sure how user is going to use it. Could
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 Vinogra
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
wrote:
> I think I am missing som
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 wrote:
> Dmitriy,
>
> In ca
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,
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
10 matches
Mail list logo
