SSLParameters for SslContextFactory
Hi all, I want to add SSLParameters for SslContextFactory. Right now there's no way to specify a particular set of cipher suites that you want to use. there's even old request to add this functionality: https://issues.apache.org/jira/browse/IGNITE-6167 even with current API you can achieve this, but this requires a lot of boilerplate code, to avoid this I added SSLParameters, that would be applied to all SSL connections, please review my pull request: https://github.com/apache/ignite/pull/4440 I think this patch covers 6167, so I want to push it in context of this ticket. Thanks, Mike.
Re: SSLParameters for SslContextFactory
Hi all, as was suggested, I removed all mention about SSLParameters and replaced it with a simple String[]. I added configurations for protocols and cipher suites. Please, review <https://github.com/apache/ignite/pull/4440/files>. Thanks, Mike. 2018-07-30 13:58 GMT+03:00 Vladimir Ozerov : > Agree. It is much easier for user to set a collection of strings > (especially from Spring), rather than construct some complex Java 8 object. > Also we need to remember that this feature should be propagated to all thin > clients and .NET integration. String getter/setter is only way to maintain > API consistency across various platforms. > > On Thu, Jul 26, 2018 at 9:16 PM Ilya Kasnacheev > > wrote: > > > Hello! > > > > I really dislike the fact that SSLParameters has 6 setter methods, and we > > only support one of them, when two more clash with SSL settings which are > > set elsewhere. > > > > I.e. what happens if I pass SSLParameters with setAlgorithmConstraints() > or > > setProtocols() called on them? > > > > Is it possible that we will just have an array of allowed ciphers in > > configuration? > > > > Regards, > > > > -- > > Ilya Kasnacheev > > > > 2018-07-26 20:16 GMT+03:00 Michael Cherkasov < > michael.cherka...@gmail.com > > >: > > > > > Hi all, > > > > > > I want to add SSLParameters for SslContextFactory. > > > > > > Right now there's no way to specify a particular set of cipher suites > > that > > > you want to use. > > > there's even old request to add this functionality: > > > https://issues.apache.org/jira/browse/IGNITE-6167 > > > even with current API you can achieve this, but this requires a lot of > > > boilerplate code, to avoid this I added SSLParameters, that would be > > > applied to all SSL connections, please review my pull request: > > > https://github.com/apache/ignite/pull/4440 > > > > > > I think this patch covers 6167, so I want to push it in context of this > > > ticket. > > > > > > Thanks, > > > Mike. > > > > > >
Re: SSLParameters for SslContextFactory
Hi all, Looks like no one has objections about the API I want to introduce. Could someone please review and push my patch? Thanks, Mike. вт, 31 июл. 2018 г. в 13:02, Mikhail Cherkasov : > > I have commented your change: setProtocols is still redundant since we > have protocol in sslContextFactory. > > it's not the same, the protocol field allows to set only one particular > protocol, while protocols allow you to set several different versions, for > example with protocols you can set: > TLSv1.1 and TLSv1.2, but exclude TLSv1.0. > > > there is a caveat with ciphers list: by default SSL will fail if you ever > list a cipher there that is not present in current JVM > > these are options for subtle SSL configuration, so it requires some > understanding what you do. > > On Mon, Jul 30, 2018 at 6:54 PM Ilya Kasnacheev > > wrote: > > > Hello! > > > > Thank you! I have commented your change: setProtocols is still redundant > > since we have protocol in sslContextFactory. > > > > BTW, there is a caveat with ciphers list: by default SSL will fail if you > > ever list a cipher there that is not present in current JVM, even if the > > rest of them are present and can be used. Thus the configuration becomes > > fragile. However I don't think it's our job to take care of that. > > > > Regards, > > > > -- > > Ilya Kasnacheev > > > > 2018-07-30 18:12 GMT+03:00 Michael Cherkasov < > michael.cherka...@gmail.com > > >: > > > > > Hi all, > > > > > > as was suggested, I removed all mention about SSLParameters and > replaced > > it > > > with a simple String[]. > > > I added configurations for protocols and cipher suites. > > > > > > Please, review <https://github.com/apache/ignite/pull/4440/files>. > > > > > > Thanks, > > > Mike. > > > > > > > > > > > > 2018-07-30 13:58 GMT+03:00 Vladimir Ozerov : > > > > > > > Agree. It is much easier for user to set a collection of strings > > > > (especially from Spring), rather than construct some complex Java 8 > > > object. > > > > Also we need to remember that this feature should be propagated to > all > > > thin > > > > clients and .NET integration. String getter/setter is only way to > > > maintain > > > > API consistency across various platforms. > > > > > > > > On Thu, Jul 26, 2018 at 9:16 PM Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com > > > > > > > > > wrote: > > > > > > > > > Hello! > > > > > > > > > > I really dislike the fact that SSLParameters has 6 setter methods, > > and > > > we > > > > > only support one of them, when two more clash with SSL settings > which > > > are > > > > > set elsewhere. > > > > > > > > > > I.e. what happens if I pass SSLParameters with > > > setAlgorithmConstraints() > > > > or > > > > > setProtocols() called on them? > > > > > > > > > > Is it possible that we will just have an array of allowed ciphers > in > > > > > configuration? > > > > > > > > > > Regards, > > > > > > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > 2018-07-26 20:16 GMT+03:00 Michael Cherkasov < > > > > michael.cherka...@gmail.com > > > > > >: > > > > > > > > > > > Hi all, > > > > > > > > > > > > I want to add SSLParameters for SslContextFactory. > > > > > > > > > > > > Right now there's no way to specify a particular set of cipher > > suites > > > > > that > > > > > > you want to use. > > > > > > there's even old request to add this functionality: > > > > > > https://issues.apache.org/jira/browse/IGNITE-6167 > > > > > > even with current API you can achieve this, but this requires a > lot > > > of > > > > > > boilerplate code, to avoid this I added SSLParameters, that would > > be > > > > > > applied to all SSL connections, please review my pull request: > > > > > > https://github.com/apache/ignite/pull/4440 > > > > > > > > > > > > I think this patch covers 6167, so I want to push it in context > of > > > this > > > > > > ticket. > > > > > > > > > > > > Thanks, > > > > > > Mike. > > > > > > > > > > > > > > > > > > > > > > > -- > Thanks, > Mikhail. >
Spring3 support
Hi all, I want to integrate the following change: https://github.com/apache/ignite/pull/3147/ It adds spring3 support. With Ignite versions older 2.1 you can to force maven to use sprint3 dependency and everything would work fine. With newer versions this doesn't work, because now Ignite uses spring4 specific features and spring3 and ignite 2.1+ don't work simultaneously on one project. If you need ignite 2.1+ you have to update spring in your project to version 4 at least, however, it isn't always possible to do so. So I want to add a new module that has no spring4 specific features and itself depends on spring3, with this module you don't even need to force maven to use specific spring version, you just can import ignite-spring3 and that's it. This will allow updating ignite version in legacy apps easier and increase ignite 2+ adaptation. Any thoughts? Objections? Thanks, Mike.
Re: Spring3 support
Hi Val, >What are the features that depend on Spring 4? at least this one breaks compatibility for sure with spring3: https://github.com/gridgain/apache-ignite/commit/ dde348607ed266f87bf594cb2a221ec39d84cfdb Thanks, Mike. 2018-01-12 2:32 GMT+03:00 Valentin Kulichenko : > Mike, > > What are the features that depend on Spring 4? > > -Val > > On Thu, Jan 11, 2018 at 12:42 PM, Michael Cherkasov < > michael.cherka...@gmail.com> wrote: > > > Hi all, > > > > I want to integrate the following change: > > https://github.com/apache/ignite/pull/3147/ > > > > It adds spring3 support. > > > > With Ignite versions older 2.1 you can to force maven to use sprint3 > > dependency and everything would work fine. > > With newer versions this doesn't work, because now Ignite uses spring4 > > specific features and spring3 and ignite 2.1+ don't work simultaneously > on > > one project. > > > > If you need ignite 2.1+ you have to update spring in your project to > > version 4 at least, however, it isn't always possible to do so. > > So I want to add a new module that has no spring4 specific features and > > itself depends on spring3, with this module you don't even need to force > > maven to use specific spring version, you just can import ignite-spring3 > > and that's it. > > > > This will allow updating ignite version in legacy apps easier and > increase > > ignite 2+ adaptation. > > > > Any thoughts? Objections? > > > > Thanks, > > Mike. > > >
Re: Spring3 support
Hi all, as I can see there are no objections, also the fix was reviewed by Anton V and Andrey G: https://issues.apache.org/jira/browse/IGNITE-7050 Could one of committer please integrate the change? Thanks, Mike . 2018-01-12 18:06 GMT+03:00 Michael Cherkasov : > Hi Val, > > >What are the features that depend on Spring 4? > at least this one breaks compatibility for sure with spring3: > https://github.com/gridgain/apache-ignite/commit/dde348607ed > 266f87bf594cb2a221ec39d84cfdb > > Thanks, > Mike. > > 2018-01-12 2:32 GMT+03:00 Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > >> Mike, >> >> What are the features that depend on Spring 4? >> >> -Val >> >> On Thu, Jan 11, 2018 at 12:42 PM, Michael Cherkasov < >> michael.cherka...@gmail.com> wrote: >> >> > Hi all, >> > >> > I want to integrate the following change: >> > https://github.com/apache/ignite/pull/3147/ >> > >> > It adds spring3 support. >> > >> > With Ignite versions older 2.1 you can to force maven to use sprint3 >> > dependency and everything would work fine. >> > With newer versions this doesn't work, because now Ignite uses spring4 >> > specific features and spring3 and ignite 2.1+ don't work simultaneously >> on >> > one project. >> > >> > If you need ignite 2.1+ you have to update spring in your project to >> > version 4 at least, however, it isn't always possible to do so. >> > So I want to add a new module that has no spring4 specific features and >> > itself depends on spring3, with this module you don't even need to force >> > maven to use specific spring version, you just can import ignite-spring3 >> > and that's it. >> > >> > This will allow updating ignite version in legacy apps easier and >> increase >> > ignite 2+ adaptation. >> > >> > Any thoughts? Objections? >> > >> > Thanks, >> > Mike. >> > >> > >
Re: Spring3 support
Hi Andrey, I agree with you after migration to jav8/9 there's no way to support spring3 in Ignite. So I think we shouldn't integrate this patch into master and people who need spring3 support can apply the patch to ignite 2.3 release and use their own build. Thanks, Mike. 2018-01-16 18:23 GMT+03:00 Andrey Gura : > Guys, > > I doubt that we should include spring-3 module in Apache Ignite 2.4 > because we will drop Java 7 support. Only Spring Framework 4.x > supports Java 8 without any limitations. > > Thoughts? > > On Tue, Jan 16, 2018 at 6:01 PM, Michael Cherkasov > wrote: > > Hi all, > > > > as I can see there are no objections, also the fix was reviewed by Anton > V > > and Andrey G: > > https://issues.apache.org/jira/browse/IGNITE-7050 > > > > Could one of committer please integrate the change? > > > > Thanks, > > Mike > > . > > > > 2018-01-12 18:06 GMT+03:00 Michael Cherkasov < > michael.cherka...@gmail.com>: > > > >> Hi Val, > >> > >> >What are the features that depend on Spring 4? > >> at least this one breaks compatibility for sure with spring3: > >> https://github.com/gridgain/apache-ignite/commit/dde348607ed > >> 266f87bf594cb2a221ec39d84cfdb > >> > >> Thanks, > >> Mike. > >> > >> 2018-01-12 2:32 GMT+03:00 Valentin Kulichenko < > >> valentin.kuliche...@gmail.com>: > >> > >>> Mike, > >>> > >>> What are the features that depend on Spring 4? > >>> > >>> -Val > >>> > >>> On Thu, Jan 11, 2018 at 12:42 PM, Michael Cherkasov < > >>> michael.cherka...@gmail.com> wrote: > >>> > >>> > Hi all, > >>> > > >>> > I want to integrate the following change: > >>> > https://github.com/apache/ignite/pull/3147/ > >>> > > >>> > It adds spring3 support. > >>> > > >>> > With Ignite versions older 2.1 you can to force maven to use sprint3 > >>> > dependency and everything would work fine. > >>> > With newer versions this doesn't work, because now Ignite uses > spring4 > >>> > specific features and spring3 and ignite 2.1+ don't work > simultaneously > >>> on > >>> > one project. > >>> > > >>> > If you need ignite 2.1+ you have to update spring in your project to > >>> > version 4 at least, however, it isn't always possible to do so. > >>> > So I want to add a new module that has no spring4 specific features > and > >>> > itself depends on spring3, with this module you don't even need to > force > >>> > maven to use specific spring version, you just can import > ignite-spring3 > >>> > and that's it. > >>> > > >>> > This will allow updating ignite version in legacy apps easier and > >>> increase > >>> > ignite 2+ adaptation. > >>> > > >>> > Any thoughts? Objections? > >>> > > >>> > Thanks, > >>> > Mike. > >>> > > >>> > >> > >> >
Re: LOCAL cache on client
Hi Dmitry, I think we should make a user to explicitly create data region on a client. Client nodes aren't supposed to be used for data storing, so if someone what to use a local cache on a client node, let's make him/her create data region explicitly. Just to make sure that user knows what he/she is doing. Thanks, Mike. 2018-02-01 7:36 GMT-08:00 Dmitry Karachentsev : > Hello everyone! > > We have an erroneous use case when client tries to create LOCAL cache, but > by default it does not initiates default data region. So client gets NPE. > [1] > > I think it should be a lazy data region initialization on client. Do you > have any concerns about this approach or other proposals? > > [1] https://issues.apache.org/jira/browse/IGNITE-7572 > > Thanks! > >
Re: IEP-54: Schema-first approach for 3.0
Hi all, I reviewed the mail thread and proposal page and I still don't fully understand what is going to be changed, I would really appreciate it if you will answer a few questions: 1. Are you going to leave only one schema per cache? if so, will be there an option to have a table with arbitrary objects(pure KV case)? 2. What options will Apache Ignite 3.0 have to define schema? SchemaBuilder and SQL only? Is there an option to put the schema definition to the configuration?(I really don't like this, I would prefer to have separate scripts to create schemas) 3. Is there a way to change field type? if yes, can it be done in runtime? 4. Looks like BinaryMarshaller is going to be re-worked too, is there any IEP for this? 5. I don't like automatic schema evaluation when a new field is added automatically on record put, so is there a way to prohibit this behavior? I think all schema changes should be done only explicitly except initial schema creation. Thanks, Mike. пн, 21 дек. 2020 г. в 06:40, Andrey Mashenkov : > Hi, Igniters. > > We all know that the current QueryEntity API is not convenient and needs to > be reworked. > So, I'm glad to share PR [1] with schema configuration public API for > Ignite 3.0. > > New schema configuration uses Builder pattern, which looks more comfortable > to use. > > In the PR you will find a 'schema' package with the API itself, and a draft > implementation in 'internal' sub-package, > and a test that demonstrates how the API could be used. > > Please note: > > * Entrypoint is 'SchemaBuilders' class with static factory methods. > * The implementation is decoupled and can be easily extracted to separate > module if we decide to do so. > * Some columns types (e.g. Date/Time) are missed, they will be added lately > in separate tickes. > * Index configuration extends marker interface that makes possible to > implement indexes of new types in plugins. > Hopfully, we could add a persistent geo-indices support in future. > * Supposedly, current table schema can be changed via builder-like > structure as it is done if JOOQ project. See 'TableModificationBuilder' for > details. > I'm not sure 'SchemaTable' should have 'toBuilder()' converter for that > purpose as it is a Schema Manager responsibility to create mutator objects > from the current schema, > but implementing the Schema manager is out of scope and will be designed > within the next task. > * Interfaces implementations are out of scope. I did not intend to merge > them right now, but for test/demostration purposes. > > It is NOT the final version and some may be changed before the first > release of course. > For now, we have to agree if we can proceed with this approach or some > issues should be resolved at first. > > Any thoughts or objections? > Are interfaces good enough to be merged within the current ticket? > > > https://issues.apache.org/jira/browse/IGNITE-13748 > > On Thu, Nov 26, 2020 at 2:33 PM Юрий wrote: > > > A little bit my thoughts about unsigned types: > > > > 1. Seems we may support unsign types > > 2. It requires adding new types to the internal representation, protocol, > > e.t.c. > > 3. internal representation should be the same as we keep sign types. So > it > > will not requires more memory > > 4. User should be aware of specifics such types for platforms which not > > support unsigned types. For example, a user could derive -6 value in Java > > for 250 unsigned byte value (from bits perspective will be right). I > think > > We shouldn't use more wide type for such cases, especially it will be bad > > for unsigned long when we require returns BigInteger type. > > 5. Possible it requires some suffix/preffix for new types like a '250u' - > > it means that 250 is an unsigned value type. > > 6. It requires a little bit more expensive comparison logic for indexes > > 7. It requires new comparison logic for expressions. I think it not > > possible for the current H2 engine and probably possible for the new > > Calcite engine. Need clarification from anybody who involved in this part > > > > WDYT? > > > > вт, 24 нояб. 2020 г. в 18:36, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > > > Actually, we can support comparisons in 3.0: once we the actual type > > > information, we can make proper runtime adjustments and conversions to > > > treat those values as unsigned - it will be just a bit more expensive. > > > > > > вт, 24 нояб. 2020 г. в 18:32, Pavel Tupitsyn : > > > > > > > > SQL range queries it will break > > > > > WHERE x > y may return wrong results > > > > > > > > Yes, range queries, inequality comparisons and so on are broken > > > > for unsigned data types, I think I mentioned this somewhere above. > > > > > > > > Again, in my opinion, we can document that SQL is not supported on > > those > > > > types, > > > > end of story. > > > > > > > > On Tue, Nov 24, 2020 at 6:25 PM Alexey Goncharuk < > > > > alexey.goncha...@gmail.com> > > > > wrote: > > > > > > > > > Folks, I think this is
Re: IEP-54: Schema-first approach for 3.0
Hi Val, Andrey, thank you for clarifying. I still have a few comments. 1. one table == one schema. KV vs SQL: Looks like all agreed that KV is just a special case of a regular table with (blob,blob) schema. I worry about the case when the user starts from KV case and later will try to expand it and try to leverage SQL for the existing KV table it won't be able to do so and will require to reload data. which isn't convenient and sometimes not even possible. Is it possible to extract a new field from (blob, blob) schema and apply index on it? 2. Could you please also list all ways of schema definition in the IEP? It significant change and I bet the main point of this IEP, everyone hates QueryEntities, they are difficult to manage and in general, it's very confusing to have a data model(schemas) and node/cluster configuration in one place. So there will be SchemaBuilder and SQL to define schemas, but Andrey also mentioned annotations. I personally against configuration via annotations, while it's convenient for development, it difficult to manage because different classes can be deployed on different clients/servers nodes and it can lead to unpredictable results. 3. IEP doesn't mention field type changes, only drop/add fields. Field type changes are extremely painful right now(if even possible), so it would be nice if some scenarios would be supported(like int8->int16, or int8->String). 4. got it, I thought IEP will have more details about the implementation. I've seen Andrey even sent benchmark results for a new serialization, will ping him about this. 5. Thanks for the clarification. I had a wrong understanding of strick mode. вт, 29 дек. 2020 г. в 19:32, Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Hi Mike, > > Thanks for providing your feedback. Please see my comments below. > > I would also encourage you to go through the IEP-54 [1] - it has a lot of > detail on the topic. > > [1] > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach > > -Val > > On Mon, Dec 28, 2020 at 11:22 PM Michael Cherkasov < > michael.cherka...@gmail.com> wrote: > > > Hi all, > > > > I reviewed the mail thread and proposal page and I still don't fully > > understand what is going to be changed, I would really appreciate it if > you > > will answer a few questions: > > > > 1. Are you going to leave only one schema per cache? if so, will be there > > an option to have a table with arbitrary objects(pure KV case)? > > > > My opinion is that KV case should be natively supported. I think this still > needs to be thought over, my current view on this is that we should have > separate APIs for KV and more generic storages. KV storage can be > implemented as a "table" with two BLOB fields where we will store > serialized key-value pairs. That would imply deserialization on read, but I > believe this is OK for KV use cases. I'm happy to hear other ideas though > :) > > > > 2. What options will Apache Ignite 3.0 have to define schema? > SchemaBuilder > > and SQL only? Is there an option to put the schema definition to the > > configuration?(I really don't like this, I would prefer to have > > separate scripts to create schemas) > > > > There will be no such thing as a static configuration in the first place. > Tables and schemas are created in runtime. Even if there is a file provided > on node startup, this file is only applied in the scope of the 'start' > operation. All configurations will be stored in a meta storage available to > all nodes, as opposed to individual files. > > > > 3. Is there a way to change field type? if yes, can it be done in > runtime? > > > > Absolutely! IEP-54 has a whole section about schema evolution. > > > > 4. Looks like BinaryMarshaller is going to be re-worked too, is there any > > IEP for this? > > > > BinaryMarshaller as a tool for arbitrary object serialization will be gone, > but we will reuse a lot of its concept to implement an internal tuple > serialization mechanism. IEP-54 has the description of the proposed data > format. > > > > 5. I don't like automatic schema evaluation when a new field is added > > automatically on record put, so is there a way to prohibit this behavior? > > I think all schema changes should be done only explicitly except initial > > schema creation. > > > > The way I see it is that we should have two modes: schema-first and > schema-last. Schema-first means exactly what you've described - schemas are > defined and updated explicitly by the user. In the schema-last mode, > the user does not deal with schemas, as they are inferred
Error Codes
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.
Re: Error Codes
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 : > 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 >: > >> 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. >> >
