ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Error Codes
Date Tue, 05 Jan 2021 22:41:23 GMT
Val, excellent, thanks.

Here is the ticket: https://issues.apache.org/jira/browse/IGNITE-3690

Mike, feel free to put useful pointers there.

-
Denis


On Tue, Jan 5, 2021 at 2:31 PM Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:

> Mike, Denis,
>
> Having error codes certainly makes sense. Please send the ticket link, and
> we'll go from there.
>
> -Val
>
> On Mon, Jan 4, 2021 at 7:50 PM Denis Magda <dmagda@apache.org> wrote:
>
> > Do back this idea up of having a glossary of common errors. There is even
> > a ticket for that I created a couple of years ago. Can search for it
> later.
> >
> > Val, how about the 3.0 suggestion? Let’s introduce error codes.
> >
> > On Monday, January 4, 2021, Michael Cherkasov <
> michael.cherkasov@gmail.com>
> > wrote:
> >
> >> Hi Ilya,
> >>
> >> It's about logs only, I don't think we need this at the API level. Error
> >> codes will make the solutions more searchable.
> >> Plus we can build troubleshooting guides based on it, it will help us
> >> gather information from user list and StackOverflow.
> >>
> >> Even a solution for trivial cases will be helpful, once I was requested
> >> to join the call late evening because ignite failed to copy WAL file and
> >> there just was no space on the disk.
> >> While the error was obvious for me, it's not obvious for all users.
> >>
> >> Let's start from something simple, just assign error codes to
> >> absolutely all exceptions first. So next year or two user list will
> full of
> >> error codes and solutions for them.
> >>
> >> Might be it's a change for Ignite 3.0? @Val, I think you can help with
> >> this question.
> >>
> >> Any thoughts/comments?
> >>
> >> Thanks,
> >> Mike.
> >>
> >> сб, 2 янв. 2021 г. в 12:18, Ilya Kasnacheev <ilya.kasnacheev@gmail.com
> >:
> >>
> >>> Hello!
> >>>
> >>> I don't think there's a direct link between an exception thrown in
> >>> depths of Ignite code, and specific error which may be reported to
> user.
> >>>
> >>> A notorious example is CorruptedTreeException which is known to be
> >>> thrown due to incorrect field type in binary object or bad SQL cast.
> So we
> >>> could document it "If you get IGN13 error this means your persistence
> is
> >>> corrupted beyond repair. This, or you have a typo in your SQL." - of
> course
> >>> it will not help anyone.
> >>>
> >>> This means we can't get to the desired result by application of 1.
> >>>
> >>> There's got to be a different plan. First of all, we need to decide
> >>> what's our target. Is it log, or is it API?
> >>>
> >>> Regards,
> >>> --
> >>> Ilya Kasnacheev
> >>>
> >>>
> >>> пт, 1 янв. 2021 г. в 02:07, Michael Cherkasov <
> >>> michael.cherkasov@gmail.com>:
> >>>
> >>>> Hi folks,
> >>>>
> >>>> I was thinking how we can simplify Ignite clusters troubleshooting and
> >>>> the best of course if the cluster can do self-healing, like
> transaction
> >>>> cancellation if tx blocks exchange or note restart on OOM error.
> However,
> >>>> sometimes those mechanisms don't work well or user interaction is
> required.
> >>>> Not all errors are obvious for users and it's not clear what actions
> >>>> required to restore the cluster.
> >>>> If you google exceptions or error messages and the results can be
> >>>> ambiguous and not certain because different errors can have similar
> >>>> exceptions and you need to analyze stack trace to distinguish them.
So
> >>>> googling isn't a straight and easy process in this case.
> >>>> Almost all major DBs have error codes[1][2][3]
> >>>> Let's do the same for Ignite, error codes easy to google, so user/dev
> >>>> list will be significantly more useful. We can have documentation
> with an
> >>>> error code registry and solutions for the errors.
> >>>>
> >>>> To implement this we need to do the following:
> >>>> 1. all error messages/exceptions must have a unique error code(so, all
> >>>> new PR must NOT be accepted if any exceptions/errors don't have error
> >>>> codes.)
> >>>> 2. to avoid error code duplication, all error codes will be stored as
> >>>> files under some folder.
> >>>> 3. those files can be a source of documentation for this error code.
> >>>>
> >>>> All this files can be empty, but futher, if exception will apper on
> >>>> user list and someone will find solution, first, other people can
> easialy
> >>>> google it by error code, and second, we can build documentation for
> this
> >>>> error code base on user-list thread/stackoverflow/other source.
> >>>>
> >>>> Any thoughts?
> >>>>
> >>>> [1] Mysql
> >>>> https://dev.mysql.com/doc/refman/8.0/en/error-message-elements.html
> >>>> [2] OracleDB https://docs.oracle.com/pls/db92/db92.error_search
> >>>> [3] PostgreSQL
> >>>> https://www.postgresql.org/docs/10/errcodes-appendix.html
> >>>>
> >>>> Thanks,
> >>>> Mike.
> >>>>
> >>>
> >
> > --
> > -
> > Denis
> >
> >
>

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