[jira] [Created] (IGNITE-14547) NPE in control.sh if there is unknown argument after --cache indexes_force_rebuild
Ilya Kazakov created IGNITE-14547:
-
Summary: NPE in control.sh if there is unknown argument after
--cache indexes_force_rebuild
Key: IGNITE-14547
URL: https://issues.apache.org/jira/browse/IGNITE-14547
Project: Ignite
Issue Type: Bug
Components: control.sh
Affects Versions: 2.10
Reporter: Ilya Kazakov
Assignee: Ilya Kazakov
./control.sh --cache indexes_force_rebuild --foo
gets NPE instead of "Unknown argument: --foo" message
{code:java}
java.lang.NullPointerException
Command [] finished with code: 4
Error stack trace:
java.lang.NullPointerException
at
org.apache.ignite.internal.commandline.cache.CacheIndexesForceRebuild.parseArguments(CacheIndexesForceRebuild.java:210)
at
org.apache.ignite.internal.commandline.cache.CacheCommands.parseArguments(CacheCommands.java:97)
at
org.apache.ignite.internal.commandline.CommonArgParser.parseAndValidate(CommonArgParser.java:241)
at
org.apache.ignite.internal.commandline.CommandHandler.execute(CommandHandler.java:244)
at
org.apache.ignite.internal.commandline.CommandHandler.main(CommandHandler.java:141){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Metrics naming formalization.
Hi, Mikhail! I've looked at the problem and the fix. The root cause of the problem is MetricsRegistry design which allows to register metrics in two ways: - using a family of methods like MetricRegistre.register(.., XxxSupplier, ...) and MetricRegistry.xxxMetric. These methods firstly create metrics and take into account registry's name. These methods provide the right way for registering metrics in MetricRegistry. - using the method MetricRegistry.register(Metric metric). This method takes as a parameter an already created metric which was created out of the metric registry context. This method is the wrong (roughly speaking) way for registering metrics in MetricRegistry. Using the right approach for metrics registering is a guaranteed way to avoid problems like described in [1]. Moreover, this approach does not require any metrics naming formalization because it hides internal naming details from an user. So, IMHO, the issue [2] ideally should be re-fixed in a right way. Also, ideally, we should limit the visibility scope of metric classes constructors and do not allow instantiate these classes directly. [1] https://issues.apache.org/jira/browse/IGNITE-14376 [2] https://issues.apache.org/jira/browse/IGNITE-14428 On Fri, Apr 9, 2021 at 1:25 PM Mikhail Petrov wrote: > > Hello, Igniters. > > I faced the following problem with the metrics - JmxMetricExporter fails > to export discovery metrics (ticket - [1]). > > The main reason: JMX exporter assumes that each metric name must start > with the name of the registry it belongs to, but discovery metrics do > not obey this naming convection. > > I propose to formalize the names of the metrics included in the metrics > registry so that they always start with the name of the register. And > add corresponding assertions (ticket - [2]). > It helps to make the metric naming consistent and fixes the mentioned > above issue. > > The following metric names are proposed to be changed: > > JoinedNodes -> io.discovery.JoinedNodes > LeftNodes -> io.discovery.LeftNodes > FailedNodes -> io.discovery.FailedNodes > PendingMessagesRegistered -> io.discovery.PendingMessagesRegistered > CommunicationErrors -> io.discovery.CommunicationErrors > CurrentTopologyVersion -> io.discovery.CurrentTopologyVersion > > Any objections? > > > [1] - https://issues.apache.org/jira/browse/IGNITE-14376 > [2] - https://issues.apache.org/jira/browse/IGNITE-14428 >
Re: Stop sending IGNITE Created e-mails to dev@
+1 for new JIRA issues -1 for MTCGA notifications Why we should hide errors from the dev-list? Who should take care of issues reported by MTCGA.Bot in this case? We must apply stricter rules for such issues: a commit leading to an error must be reverted. On Wed, 14 Apr 2021 at 20:00, Denis Mekhanikov wrote: > > Huge +1 to this. > > I've already brought up this topic in the past: > http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html > I hope some day newcomers won't need to set up their email filters when > they come to the developers list. > > Denis > > ср, 14 апр. 2021 г. в 18:07, Atri Sharma : > > > +1 to move issues to the issues list. > > > > For MTCGA, maybe build@? > > > > On Wed, Apr 14, 2021 at 8:35 PM Ilya Kasnacheev wrote: > > > > > > Hello! > > > > > > We have a discussion on how to ensure best engagement in dev@ list, and > > it > > > seems that Issue Created emails from IGNITE project consume a lot of > > screen > > > space, it's hard to spot genuine discussions in > > > https://lists.apache.org/list.html?dev@ignite.apache.org for example. > > > > > > We already have issues@ mailing list. I propose that we stop sending any > > > JIRA emails to dev@. If anyone wishes to get just Created emails, they > > can > > > subscribe to these messages in their JIRA account settings. I imagine > > most > > > of you already filter these messages out, so you may need to adjust your > > > filters slightly. > > > > > > A distant second is MTCGA messages, which are also autogenerated and not > > > informative for most readers of the channel, since they are at best > > > targeted at a single committer and at worst flaky. > > > > > > Where could we move those? What is your opinion here, on both issues? > > > > > > Regards, > > > > -- > > Regards, > > > > Atri > > Apache Concerted > >
Re: Stop sending IGNITE Created e-mails to dev@
Huge +1 to this. I've already brought up this topic in the past: http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html I hope some day newcomers won't need to set up their email filters when they come to the developers list. Denis ср, 14 апр. 2021 г. в 18:07, Atri Sharma : > +1 to move issues to the issues list. > > For MTCGA, maybe build@? > > On Wed, Apr 14, 2021 at 8:35 PM Ilya Kasnacheev wrote: > > > > Hello! > > > > We have a discussion on how to ensure best engagement in dev@ list, and > it > > seems that Issue Created emails from IGNITE project consume a lot of > screen > > space, it's hard to spot genuine discussions in > > https://lists.apache.org/list.html?dev@ignite.apache.org for example. > > > > We already have issues@ mailing list. I propose that we stop sending any > > JIRA emails to dev@. If anyone wishes to get just Created emails, they > can > > subscribe to these messages in their JIRA account settings. I imagine > most > > of you already filter these messages out, so you may need to adjust your > > filters slightly. > > > > A distant second is MTCGA messages, which are also autogenerated and not > > informative for most readers of the channel, since they are at best > > targeted at a single committer and at worst flaky. > > > > Where could we move those? What is your opinion here, on both issues? > > > > Regards, > > -- > Regards, > > Atri > Apache Concerted >
Re: Stop sending IGNITE Created e-mails to dev@
+1 to move issues to the issues list. For MTCGA, maybe build@? On Wed, Apr 14, 2021 at 8:35 PM Ilya Kasnacheev wrote: > > Hello! > > We have a discussion on how to ensure best engagement in dev@ list, and it > seems that Issue Created emails from IGNITE project consume a lot of screen > space, it's hard to spot genuine discussions in > https://lists.apache.org/list.html?dev@ignite.apache.org for example. > > We already have issues@ mailing list. I propose that we stop sending any > JIRA emails to dev@. If anyone wishes to get just Created emails, they can > subscribe to these messages in their JIRA account settings. I imagine most > of you already filter these messages out, so you may need to adjust your > filters slightly. > > A distant second is MTCGA messages, which are also autogenerated and not > informative for most readers of the channel, since they are at best > targeted at a single committer and at worst flaky. > > Where could we move those? What is your opinion here, on both issues? > > Regards, -- Regards, Atri Apache Concerted
Stop sending IGNITE Created e-mails to dev@
Hello! We have a discussion on how to ensure best engagement in dev@ list, and it seems that Issue Created emails from IGNITE project consume a lot of screen space, it's hard to spot genuine discussions in https://lists.apache.org/list.html?dev@ignite.apache.org for example. We already have issues@ mailing list. I propose that we stop sending any JIRA emails to dev@. If anyone wishes to get just Created emails, they can subscribe to these messages in their JIRA account settings. I imagine most of you already filter these messages out, so you may need to adjust your filters slightly. A distant second is MTCGA messages, which are also autogenerated and not informative for most readers of the channel, since they are at best targeted at a single committer and at worst flaky. Where could we move those? What is your opinion here, on both issues? Regards,
[jira] [Created] (IGNITE-14546) Calcite engine. MIN/MAX aggregates doesn't support string types
Taras Ledkov created IGNITE-14546:
-
Summary: Calcite engine. MIN/MAX aggregates doesn't support string
types
Key: IGNITE-14546
URL: https://issues.apache.org/jira/browse/IGNITE-14546
Project: Ignite
Issue Type: Bug
Reporter: Taras Ledkov
MIN/MAX aggregates doesn't support string types.
e.g.
{{CREATE TABLE TEST(val VARCHAR) }}
{{INSERT INTO TEST VALUES ('A'), ('B'), ('C') }}
{{ SELECT MIN(val), MAX(val) FROM TEST}}
Test: {{src/test/sql/aggregate/aggregates/test_aggr_string.test}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14545) Calcite engine. Unicode literal not supported
Taras Ledkov created IGNITE-14545:
-
Summary: Calcite engine. Unicode literal not supported
Key: IGNITE-14545
URL: https://issues.apache.org/jira/browse/IGNITE-14545
Project: Ignite
Issue Type: Bug
Reporter: Taras Ledkov
Unicode literal not supported.
e.g. {{SELECT }}
Tests:
{{aggregate/aggregates/test_aggr_string.test}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14544) Calcite engine. Implement DISTING aggregates
Taras Ledkov created IGNITE-14544:
-
Summary: Calcite engine. Implement DISTING aggregates
Key: IGNITE-14544
URL: https://issues.apache.org/jira/browse/IGNITE-14544
Project: Ignite
Issue Type: Bug
Reporter: Taras Ledkov
Now, DISTINCT aggregates not implemented.
(e.g. {{SELECT COUNT (DISTINCT lastName) FROM person}})
Tests:
{{aggregate/aggregates/test_count.test_ignored}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14543) Calcite engine. COUNT agregate on scalar values fails
Taras Ledkov created IGNITE-14543:
-
Summary: Calcite engine. COUNT agregate on scalar values fails
Key: IGNITE-14543
URL: https://issues.apache.org/jira/browse/IGNITE-14543
Project: Ignite
Issue Type: Bug
Reporter: Taras Ledkov
Failed queries:
{{SELECT COUNT(*)}}
{{SELECT COUNT(NULL)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14542) Calcite engine. Need to support TableFunctions / SYSTEM_RANGE dynamic table
Taras Ledkov created IGNITE-14542:
-
Summary: Calcite engine. Need to support TableFunctions /
SYSTEM_RANGE dynamic table
Key: IGNITE-14542
URL: https://issues.apache.org/jira/browse/IGNITE-14542
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Taras Ledkov
A lot of cases require dynamic range data source.
Tests:
{{aggregate/aggregates/test_perfect_ht.test_ignored}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14541) Calcite engine. HAVING fails on scalar
Taras Ledkov created IGNITE-14541:
-
Summary: Calcite engine. HAVING fails on scalar
Key: IGNITE-14541
URL: https://issues.apache.org/jira/browse/IGNITE-14541
Project: Ignite
Issue Type: Bug
Reporter: Taras Ledkov
Query to reproduce:
{{SELECT 42 HAVING 42 > 20}}
Test: {{aggregate/having/test_scalar_having.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14540) Calcite engine. Support correlated subquery in having
Taras Ledkov created IGNITE-14540:
-
Summary: Calcite engine. Support correlated subquery in having
Key: IGNITE-14540
URL: https://issues.apache.org/jira/browse/IGNITE-14540
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Taras Ledkov
Correlated subquery in having isn't supported now.
Test: {{aggregate/having/test_corel_subquery_in_having.test_ignored}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14539) Calcite engine. Support DISTINCT ON expression
Taras Ledkov created IGNITE-14539:
-
Summary: Calcite engine. Support DISTINCT ON expression
Key: IGNITE-14539
URL: https://issues.apache.org/jira/browse/IGNITE-14539
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Taras Ledkov
Now DISTINCT ON expression isn't supported.
e.g.:
{{SELECT DISTINCT ON (lastName) firstName, lastName FROM Person WHERE ... }}
Test: {{aggregate/distinct/test_distinct_on.test_ignored}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14538) Add ScaleCube configuration
Semyon Danilov created IGNITE-14538: --- Summary: Add ScaleCube configuration Key: IGNITE-14538 URL: https://issues.apache.org/jira/browse/IGNITE-14538 Project: Ignite Issue Type: Sub-task Reporter: Semyon Danilov Right now we are using default ScaleCube parameters. ScaleCube configuration should be introduced as a part of networking configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14537) Nested arbitrary queries hangs on optimizing
Taras Ledkov created IGNITE-14537:
-
Summary: Nested arbitrary queries hangs on optimizing
Key: IGNITE-14537
URL: https://issues.apache.org/jira/browse/IGNITE-14537
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Taras Ledkov
The query with nested arbitrary subqueries aren't planned.
Test: {{subquery/test_neumann.test_ignore}}
See more: [Unnesting Arbitrary
Queries|https://subs.emis.de/LNI/Proceedings/Proceedings241/383.pdf]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14536) Handle forceful shutdown of ScaleCube cluster node
Semyon Danilov created IGNITE-14536: --- Summary: Handle forceful shutdown of ScaleCube cluster node Key: IGNITE-14536 URL: https://issues.apache.org/jira/browse/IGNITE-14536 Project: Ignite Issue Type: Bug Reporter: Semyon Danilov Assignee: Semyon Danilov Right now, if scalecube cluster node was shutdown forcefully no event will be propagated to ClusterService and topology wouldn't change -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14535) Caclite SQL engine capabilities
Taras Ledkov created IGNITE-14535: - Summary: Caclite SQL engine capabilities Key: IGNITE-14535 URL: https://issues.apache.org/jira/browse/IGNITE-14535 Project: Ignite Issue Type: Improvement Reporter: Taras Ledkov Umbrella ticket to track issues related to SQL logical tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14534) Python thin: Add script for building wheels on Windows
Igor Sapego created IGNITE-14534: Summary: Python thin: Add script for building wheels on Windows Key: IGNITE-14534 URL: https://issues.apache.org/jira/browse/IGNITE-14534 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: python-0.3.4 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: python-0.3.4 We already have scripts to build wheels on Linux, now we need script to build wheels on Windows. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Azure Cloud IP Finder
Thanks for your comments. I have moved the dependency versions for shared versions to parent POM and also for the majorly used versions for module specific dependencies. I have also fixed the Ipv6 issue and have tested with both Ipv4 and Ipv6 and it works fine. Please let me know your thoughts. Atri On Tue, Apr 13, 2021 at 9:39 PM Ilya Kasnacheev wrote: > > Hello! > > I have added more comments to the PR. > > IPv6 still needs to be supported and dependencies' versions should be moved > to parent/pom.xml, at least for shared dependencies such as log4j and > jackson, and preferably for all dependencies. > > Regards, > -- > Ilya Kasnacheev > > > вт, 13 апр. 2021 г. в 10:33, Atri Sharma : > > > Hello, > > > > Sorry for the late reply. > > > > Thank you for taking a look. Indeed, there were some issues and they > > have now been fixed. > > > > I am able to start a two node cluster with Azure IPFinder enabled and > > shut it down successfully (using Ipv4). > > > > Please see the latest iteration and let me know your thoughts and comments. > > > > Regards, > > > > Atri > > > > On Fri, Apr 9, 2021 at 4:58 PM Ilya Kasnacheev > > wrote: > > > > > > Hello! > > > > > > I have responded to the ticket after testing on live Azure. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > пт, 9 апр. 2021 г. в 08:37, Atri Sharma : > > > > > > > Hi Ilya, > > > > > > > > Please let me know if I can help with any further iterations on the PR. > > > > > > > > Regards, > > > > > > > > Atri > > > > > > > > On Wed, Apr 7, 2021 at 5:04 PM Atri Sharma wrote: > > > > > > > > > > Hi Ilya, > > > > > > > > > > Thanks for taking a look. I was able to resolve dependencies (Thanks, > > > > > Sam!) and have updated the PR. > > > > > > > > > > Copying the jars from ignite-azure to libs works for me. > > > > > > > > > > Please see and let me know your thoughts. > > > > > > > > > > Regards, > > > > > > > > > > Atri > > > > > > > > > > On Mon, Apr 5, 2021 at 9:24 PM Ilya Kasnacheev > > > > > wrote: > > > > > > > > > > > > Hello again! > > > > > > > > > > > > I re-checked our cloud discovery options by moving ignite-aws, > > > > ignite-gce, > > > > > > ignite-cloud directories from lib/optional to lib/ and trying to > > run > > > > Ignite > > > > > > with simple config taken from examples. > > > > > > > > > > > > The results are the following: > > > > > > ignite-aws seems to work (complains about unknown key) > > > > > > ignite-gce seems to work too (complains about zero length key, > > this is > > > > > > before it tries any network access so maybe there are other issues > > > > down the > > > > > > path) > > > > > > ignite-cloud (jclouds) DOES NOT work. Filed > > > > > > https://issues.apache.org/jira/browse/IGNITE-14481 . I guess this > > > > discovery > > > > > > finder is not widely used. > > > > > > ignite-azure, presently, will not work too. Please use ignite-aws > > as an > > > > > > example since it sees the most usage. > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > пн, 5 апр. 2021 г. в 16:05, Ilya Kasnacheev < > > ilya.kasnach...@gmail.com > > > > >: > > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > I'm not sure that I can see any attachment to your e-mail. Can > > you > > > > please > > > > > > > re-send? > > > > > > > > > > > > > > We could have broken some of those, I guess, since we seem to > > not run > > > > > > > integration tests for them. > > > > > > > > > > > > > > Regards, > > > > > > > -- > > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > > > > пт, 2 апр. 2021 г. в 12:59, Atri Sharma : > > > > > > > > > > > > > >> Hello, > > > > > > >> > > > > > > >> Thank you for sharing. > > > > > > >> > > > > > > >> I was finally able to replicate the issue. However, I tried with > > > > other > > > > > > >> IPFinders and ran into the same problem (attached are the logs). > > > > > > >> > > > > > > >> Not sure what is causing this? > > > > > > >> > > > > > > >> Atri > > > > > > >> > > > > > > >> On Fri, Apr 2, 2021 at 2:29 PM Ilya Kasnacheev > > > > > > >> wrote: > > > > > > >> > > > > > > > >> > Hello! > > > > > > >> > > > > > > > >> > Please find attached the log file of errors. This is > > yesterday's > > > > (Apr > > > > > > >> 1) build. > > > > > > >> > > > > > > > >> > Regards, > > > > > > >> > -- > > > > > > >> > Ilya Kasnacheev > > > > > > >> > > > > > > > >> > > > > > > > >> > пт, 2 апр. 2021 г. в 11:52, Atri Sharma : > > > > > > >> >> > > > > > > >> >> I was able to, but then, it might be that something is cached > > > > locally. > > > > > > >> >> > > > > > > >> >> What errors did you run into? (I am assuming you are trying > > with > > > > a > > > > > > >> >> build from the latest iteration of the PR). > > > > > > >> >> > > > > > > >> >> Atri > > > > > > >> >> > > > > > > >> >> On Fri, Apr 2, 2021 at 2:19 PM Ilya Kasnacheev > > > > > > >> >> wrote: > > > > > > >> >> > > > > > > > >> >> > Hello! > > > > > > >> >> >
Re: [DISCUSSION] Error handling in Ignite 3
Alexey,
ср, 14 апр. 2021 г. в 01:52, Alexey Kukushkin :
> Just some points looking questionable to me, although I realize the error
> handling style may be very opinionated:
>
>- Would it make sense splitting the proposed composite error code
>(TBL-0001) into separate numeric code (0001) and scope/category ("TBL")
> to
>avoid parsing the code when an error handler needs to analyze only the
>category or the code?
>
TBL-0001 is a *string representation* of the error. It is built from 2
byte scope id (mapped to name TBL) and 2 byte number (0001). Both
internally packed in int. No any kind of parsing will be necessary to read
scope/category.
>- "*The cause - short string description of an issue, readable by
> user.*".
>This terminology sounds confusing to me since that "cause" sounds like
> Java
>Throwable's Message to me and the "Cause" is a lower level exception.
>
The string describes the cause of error, so the name. I'm ok to rename it
to a message. It will be stored in IgniteException.message field anyway.
>- "*The action - steps for a user to resolve error...*". The action is
>very important but do we want to make it part of the IgniteException? I
> do
>not think the recovery action text should be part of the exception.
>IgniteException may include a URL pointing to the corresponding
>documentation - this is discussable.
>
This will not be the part of the exception. A user should visit the
documentation page and read the action section by corresponding error code.
>- "*All public methods throw only unchecked IgniteException*" - I assume
>we still respect JCache specification and prefer using standard Java
>exception to signal about invalid parameters.
>
Using standard java exceptions whenever possible makes sense.
>- Why we do not follow the "classic" structured exception handling
>practices in Ignite:
>
Ignite 3 will be multi language, and other languages use other error
processing models. SQL for example uses error codes.
The single exception approach simplifies and unifies error handling across
platforms for me.
> - Why do we not allow using checked exceptions? It seems to me
> sometimes forcing the user to handle an error serves as a hint and
> thus
> improves usability. For example, handling an optimistic/pessimistic
> transaction conflict/deadlock. Or handling a timeout for operations
> with
> timeouts.
>
A valid point. Checked exceptions must be used for whose methods, where
error handling is enforced, for example tx optimistic failure.
Such errors will also have corresponding error codes.
> - Why single public IgniteException and no exception hierarchy? Java
> is optimized for structured exception handling instead of using
> IF-ELSE to
> analyze the codes.
>
Exception hierarchy is not required when using error codes and applicable
only to java API, so I would avoid spending efforts on it.
> - Why no nested exceptions? Sometimes an error handler is interested
> only in high level exceptions (like Invalid Configuration) and
> sometimes
> details are needed (like specific configuration parser exceptions).
>
Nested exceptions are not forbidden to use. They can provide additional
details on the error for debug purposes, but not strictly required, because
error code + message should provide enough information to the user.
>- For async methods returning a Future we may have a universal rule on
>how to handle exceptions. For example, we may specify that any async
> method
>can throw only invalid argument exceptions. All other errors are
> reported
>via the exceptionally(IgniteException -> {}) callback even if the async
>method was executed synchronously.
>
This is ok to me.
>
>
> вт, 13 апр. 2021 г. в 12:08, Alexei Scherbakov <
> alexey.scherbak...@gmail.com
> >:
>
> > Igniters,
> >
> > I would like to start the discussion about error handling in Ignite 3 and
> > how we can improve it compared to Ignite 2.
> >
> > The error handling in Ignite 2 was not very good because of generic
> > CacheException thrown on almost any occasion, having deeply nested root
> > cause and often containing no useful information on further steps to fix
> > the issue.
> >
> > I aim to fix it by introducing some rules on error handling.
> >
> > *Public exception structure.*
> >
> > A public exception must have an error code, a cause, and an action.
> >
> > * The code - the combination of 2 byte scope id and 2 byte error number
> > within the module. This allows up to 2^16 errors for each scope, which
> > should be enough. The error code string representation can look like
> > RFT-0001 or TBL-0001
> > * The cause - short string description of an issue, readable by user.
> This
> > can have dynamic parameters depending on the error type for better user
> > experience, like "Can't write a snapshot, no space left on device {0}"
> > * The action - ste
