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 03:50:21 GMT
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>

> 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.


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