Re: New Ignite Website: Released and Check the Dev Instructions
Hi, It seems that all documents are unpublished version 2.12 documents? For example, the following documents are unpublished IndexQuery: https://ignite.apache.org/docs/2.11.0/key-value-api/using-cache-queries https://ignite.apache.org/docs/2.10.0/key-value-api/using-cache-queries https://ignite.apache.org/docs/2.9.0/key-value-api/using-cache-queries In addition, the menu tree on the left side of the document should be shared by all document versions. Is this unreasonable? 在 2021/12/15 02:29, Mauricio Stekl 写道: Thank you, Erlan. I merged your first commit into the prod website. Welcome to the Ignite community! Best, Mauricio On Tue, Dec 14, 2021 at 4:40 AM Erlan Aytpaev wrote: Hi Igniters, I've added the "Extensions" section on the "Downloads" page. Please review my pull requesthttps://github.com/apache/ignite-website/pull/91. This is my first commit. And I'm going to continue contributing updates on the website. Best Regards, Erlan. On Tue, Dec 14, 2021 at 9:55 AM Mauricio Stekl wrote: Hi, I noticed the "Extensions" section was not merged correctly into the Downloads page. I have created a ticket https://issues.apache.org/jira/browse/IGNITE-16112, and we'll be solving this as soon as possible. My apologies for the inconvenience Best, Mauricio On Mon, Dec 13, 2021 at 4:46 PM Denis Magda wrote: Igniters, Please welcome the new Ignite website:https://ignite.apache.org Hope you like it! The website uses gulpjs to simplify the dev/maintenance cycles, thus, I would encourage all of you who release Ignite (and update the downloads page) or edit any other pages to check the updated instruction: https://cwiki.apache.org/confluence/display/IGNITE/Website+Development - Denis
Re:[DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3
I'm for the second option.
Re: [DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3
Same here. The second option seems the most reasonable. -Val On Thu, Dec 16, 2021 at 8:07 AM Alexei Scherbakov < alexey.scherbak...@gmail.com> wrote: > +1 for 2 > > чт, 16 дек. 2021 г. в 18:50, Pavel Tupitsyn : > > > Option 2 seems the most sensible. > > It translates to/from other languages and should be already familiar to > > some developers. > > > > For example, with nullable checks enabled, C# treats everything as not > > null, unless specified otherwise with "?". > > Same for other languages where Option/Maybe type is present. Nothing is > > null by default. > > > > On Thu, Dec 16, 2021 at 6:14 PM Alexander Polovtcev < > > alexpolovt...@gmail.com> > > wrote: > > > > > Dear Igniters! > > > > > > I would like to propose a discussion about defining a policy regarding > > > where and how to use @Nullable/@NotNull annotations. These annotations > > are > > > used in conjunction with a static analysis engine (e.g. built in IDEA) > > and > > > are useful for avoiding null dereferencing and specifying method > > contracts. > > > > > > I can see the following possible options: > > > > > > 1. *Use both @Nullable and @NotNull annotations everywhere* (i.e. > method > > > parameters and return types, class fields). Pros: the most robust and > > > expressive variant; easy to agree on and specify. Cons: very verbose; > may > > > lead to code cluttering; > > > 2. *Use only @Nullable *for specifying method parameters that accept > null > > > or class fields that can be null, treating @NotNull as an implicit > > default. > > > Pros: correlates with the default IDEA settings (with all corresponding > > > inspections enabled); not as verbose as option 1, since nullable > > parameters > > > are quite rare. Cons: less sound and complete, especially when working > > with > > > third-party libraries that are not annotated, since we cannot apply the > > > implicit @NotNull there; > > > 3. *Use only @NotNull *and treat @Nullable as an implicit default. > Pros: > > > less verbose than option 1, better correlates with Java language > > semantics > > > (since all Java references are nullable). Cons: more verbose than > option > > 2; > > > may be impossible to properly set up the analysis engine or may require > > > switching to a different annotation provider that supports jsr-305 > > > @ParametersAreNullableByDefault; > > > 4. *Do not use @Nullable nor @NotNull*. The most radical option in case > > we > > > will not be able to agree on any of the above three. No annotations - > no > > > need for the discussion. > > > > > > What do you think? Are there any other options out there? I would like > to > > > collect as many options as possible and organize a vote some time > later. > > > > > > -- > > > With regards, > > > Aleksandr Polovtcev > > > > > > > > -- > > Best regards, > Alexei Scherbakov >
Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]
Hi Maxim, Thanks a lot! > Check the following links below. Looks good to me. чт, 16 дек. 2021 г. в 20:19, Maxim Muzafarov : > Folks, > > > I'm OK with this. Let's go through the fastest way we have. > > > Check the following links below. I'll prepare the vote shortly. > > Compare branches 2.11 and 2.11.1: > https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1 > > The release branch: > https://github.com/apache/ignite/tree/ignite-2.11.1 > > JIRA 2.11.1 version: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.11.1 > > Release notes: > https://github.com/apache/ignite/blob/ignite-2.11.1/RELEASE_NOTES.txt > > On Thu, 16 Dec 2021 at 19:30, Ilya Kasnacheev > wrote: > > > > Hello! > > > > I also agree with Stephen. If we wanted to do a stabilization release we > > should unbound it from this urgent fix. > > > > I wonder why 2.12 is not with us already, given that it was scheduled to > go > > out in August. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > чт, 16 дек. 2021 г. в 19:25, Вячеслав Коптилин >: > > > > > Hello, > > > > > > > Given that 2.12 is so close, my preference would be to limit the > scope of > > > 2.11.1 to just the log4j update. > > > I agree with Stephen. Apache Ignite 2.11.1 is an emergency release. > Using > > > log4j 2.16 instead of 2.14 is a quite small change that only requires a > > > "sanity" check and can be quickly released. A wider release scope > requires > > > full testing, IMHO. > > > > > > Thanks, > > > S. > > > > > > > > > чт, 16 дек. 2021 г. в 16:03, Maxim Muzafarov : > > > > > > > I think it is completely possible to move vote/release dates > > > > significantly forward with keeping the scope. I will take a look at > > > > the list of fixed bugs more narrowly and exclude some of them that > > > > require additional verification. > > > > > > > > On Thu, 16 Dec 2021 at 15:55, Stephen Darlington > > > > wrote: > > > > > > > > > > Given that 2.12 is so close, my preference would be to limit the > scope > > > > of 2.11.1 to just the log4j update. Would that help bring the > > > vote/release > > > > date forward? > > > > > > > > > > > On 16 Dec 2021, at 12:44, Maxim Muzafarov > wrote: > > > > > > > > > > > > Dear Ignite Community! > > > > > > > > > > > > I suggest preparing the Apache Ignite 2.11.1 release and I want > to > > > > > > propose myself to be the release manager of the minor release. > > > > > > > > > > > > > > > > > > * RELEASE TIMELINE * > > > > > > > > > > > > Scope Freeze: December 16, 2021 > > > > > > Code Freeze: December 16, 2021 > > > > > > Voting Date: December 21, 2021 > > > > > > Release Date: December 24, 2021 > > > > > > > > > > > > > > > > > > * RELEASE SCOPE * > > > > > > > > > > > > LOG4J dependency update > > > > > > https://issues.apache.org/jira/browse/IGNITE-16101 > > > > > > https://issues.apache.org/jira/browse/IGNITE-16127 > > > > > > > > > > > > B+Tree Corrupted exception when using a key extracted from a > > > > BinaryObject > > > > > > https://issues.apache.org/jira/browse/IGNITE-12911 > > > > > > > > > > > > Regression: Ignite node crash(CorruptedTreeException: B+Tree is > > > > corrupted) > > > > > > https://issues.apache.org/jira/browse/IGNITE-15943 > > > > > > > > > > > > .NET: ClientFailoverSocket sets logger too late, resulting in > null > > > > > > loggers downstream > > > > > > https://issues.apache.org/jira/browse/IGNITE-14776 > > > > > > > > > > > > The iterator of the ClientCacheQueryCursor can be closed during > > > > serialization. > > > > > > https://issues.apache.org/jira/browse/IGNITE-15346 > > > > > > > > > > > > Possible owners desync when a node is restarted while rebalancing > > > with > > > > > > enabled persistence > > > > > > https://issues.apache.org/jira/browse/IGNITE-15315 > > > > > > > > > > > > Thin client: Tx can fail if there are concurrent tx rollbacks by > > > > timeout > > > > > > https://issues.apache.org/jira/browse/IGNITE-15732 > > > > > > > > > > > > AssertionError: Unexpected rebalance on rebalanced cluster > > > > > > https://issues.apache.org/jira/browse/IGNITE-15033 > > > > > > > > > > > > JmxMetricExporterSpi throws assertion error on a filtered metric > > > > unregister > > > > > > https://issues.apache.org/jira/browse/IGNITE-15252 > > > > > > > > > > > > ClassNotFoundException on an attempt to invoke service method > from > > > > > > Java ThinClient after a cluster failover > > > > > > https://issues.apache.org/jira/browse/IGNITE-15256 > > > > > > > > > > > > NullPointerException on an attempt to create a Java ThinClient > with > > > > > > BinaryConfiguration > > > > > > https://issues.apache.org/jira/browse/IGNITE-15138 > > > > > > > > > > > > Java thin client: Type name is not cached on client-side for > > > > > > OptimizerMarshaller types > > > > > > https://issues.apache.org/jira/browse/IGNITE-15924 > > > > > > > > > > > > select count * returns multiple rows > > > > > >
Updating of configuration TC2: ci2.ignite.apache.org
Hi! TeamCity server https://ci2.ignite.apache.org/ will be unavailable on Friday 17.12 from 22:00 MSK to 00:00 MSK Works will be done to synchronize the TeamCity configuration https://ci2.ignite.apache.org/ with TeamCity https://ci.ignite.apache.org/ Best regards, Osipov Vitaliy osipov.wita...@gmail.com
Re: [DISCUSSION] Reject join of nodes with different character encodings
Andrey, agree with you, good point. чт, 16 дек. 2021 г., 16:27 Andrey Mashenkov : > Guys, > > I like the idea with a flag, but for a different purpose. > I think it is easy to detect the issue (using the flag) when > metastorage was created on a new version with a fixed charset, or on an > older version with the user-defined default. > Regarding the flag, we can choose a new strategy forcing UTF-8, or fallback > to the old one with defaultCharset and print a warning and recommendation > in log. > > Adding any compatibility stuff is absolutely error-prone because if you > fail in the middle of restoring process, you will get broken metastorage > with keys in different charsets. > At this point, there is no way to detect broken keys anymore. >
Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]
Folks, I'm OK with this. Let's go through the fastest way we have. Check the following links below. I'll prepare the vote shortly. Compare branches 2.11 and 2.11.1: https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1 The release branch: https://github.com/apache/ignite/tree/ignite-2.11.1 JIRA 2.11.1 version: https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.11.1 Release notes: https://github.com/apache/ignite/blob/ignite-2.11.1/RELEASE_NOTES.txt On Thu, 16 Dec 2021 at 19:30, Ilya Kasnacheev wrote: > > Hello! > > I also agree with Stephen. If we wanted to do a stabilization release we > should unbound it from this urgent fix. > > I wonder why 2.12 is not with us already, given that it was scheduled to go > out in August. > > Regards, > -- > Ilya Kasnacheev > > > чт, 16 дек. 2021 г. в 19:25, Вячеслав Коптилин : > > > Hello, > > > > > Given that 2.12 is so close, my preference would be to limit the scope of > > 2.11.1 to just the log4j update. > > I agree with Stephen. Apache Ignite 2.11.1 is an emergency release. Using > > log4j 2.16 instead of 2.14 is a quite small change that only requires a > > "sanity" check and can be quickly released. A wider release scope requires > > full testing, IMHO. > > > > Thanks, > > S. > > > > > > чт, 16 дек. 2021 г. в 16:03, Maxim Muzafarov : > > > > > I think it is completely possible to move vote/release dates > > > significantly forward with keeping the scope. I will take a look at > > > the list of fixed bugs more narrowly and exclude some of them that > > > require additional verification. > > > > > > On Thu, 16 Dec 2021 at 15:55, Stephen Darlington > > > wrote: > > > > > > > > Given that 2.12 is so close, my preference would be to limit the scope > > > of 2.11.1 to just the log4j update. Would that help bring the > > vote/release > > > date forward? > > > > > > > > > On 16 Dec 2021, at 12:44, Maxim Muzafarov wrote: > > > > > > > > > > Dear Ignite Community! > > > > > > > > > > I suggest preparing the Apache Ignite 2.11.1 release and I want to > > > > > propose myself to be the release manager of the minor release. > > > > > > > > > > > > > > > * RELEASE TIMELINE * > > > > > > > > > > Scope Freeze: December 16, 2021 > > > > > Code Freeze: December 16, 2021 > > > > > Voting Date: December 21, 2021 > > > > > Release Date: December 24, 2021 > > > > > > > > > > > > > > > * RELEASE SCOPE * > > > > > > > > > > LOG4J dependency update > > > > > https://issues.apache.org/jira/browse/IGNITE-16101 > > > > > https://issues.apache.org/jira/browse/IGNITE-16127 > > > > > > > > > > B+Tree Corrupted exception when using a key extracted from a > > > BinaryObject > > > > > https://issues.apache.org/jira/browse/IGNITE-12911 > > > > > > > > > > Regression: Ignite node crash(CorruptedTreeException: B+Tree is > > > corrupted) > > > > > https://issues.apache.org/jira/browse/IGNITE-15943 > > > > > > > > > > .NET: ClientFailoverSocket sets logger too late, resulting in null > > > > > loggers downstream > > > > > https://issues.apache.org/jira/browse/IGNITE-14776 > > > > > > > > > > The iterator of the ClientCacheQueryCursor can be closed during > > > serialization. > > > > > https://issues.apache.org/jira/browse/IGNITE-15346 > > > > > > > > > > Possible owners desync when a node is restarted while rebalancing > > with > > > > > enabled persistence > > > > > https://issues.apache.org/jira/browse/IGNITE-15315 > > > > > > > > > > Thin client: Tx can fail if there are concurrent tx rollbacks by > > > timeout > > > > > https://issues.apache.org/jira/browse/IGNITE-15732 > > > > > > > > > > AssertionError: Unexpected rebalance on rebalanced cluster > > > > > https://issues.apache.org/jira/browse/IGNITE-15033 > > > > > > > > > > JmxMetricExporterSpi throws assertion error on a filtered metric > > > unregister > > > > > https://issues.apache.org/jira/browse/IGNITE-15252 > > > > > > > > > > ClassNotFoundException on an attempt to invoke service method from > > > > > Java ThinClient after a cluster failover > > > > > https://issues.apache.org/jira/browse/IGNITE-15256 > > > > > > > > > > NullPointerException on an attempt to create a Java ThinClient with > > > > > BinaryConfiguration > > > > > https://issues.apache.org/jira/browse/IGNITE-15138 > > > > > > > > > > Java thin client: Type name is not cached on client-side for > > > > > OptimizerMarshaller types > > > > > https://issues.apache.org/jira/browse/IGNITE-15924 > > > > > > > > > > select count * returns multiple rows > > > > > https://issues.apache.org/jira/browse/IGNITE-14120 > > > > > > > > > > Fix StackOverflowError in case if an exception is suppressed with > > > itself > > > > > https://issues.apache.org/jira/browse/IGNITE-15716 > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > >
Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]
Hello! I also agree with Stephen. If we wanted to do a stabilization release we should unbound it from this urgent fix. I wonder why 2.12 is not with us already, given that it was scheduled to go out in August. Regards, -- Ilya Kasnacheev чт, 16 дек. 2021 г. в 19:25, Вячеслав Коптилин : > Hello, > > > Given that 2.12 is so close, my preference would be to limit the scope of > 2.11.1 to just the log4j update. > I agree with Stephen. Apache Ignite 2.11.1 is an emergency release. Using > log4j 2.16 instead of 2.14 is a quite small change that only requires a > "sanity" check and can be quickly released. A wider release scope requires > full testing, IMHO. > > Thanks, > S. > > > чт, 16 дек. 2021 г. в 16:03, Maxim Muzafarov : > > > I think it is completely possible to move vote/release dates > > significantly forward with keeping the scope. I will take a look at > > the list of fixed bugs more narrowly and exclude some of them that > > require additional verification. > > > > On Thu, 16 Dec 2021 at 15:55, Stephen Darlington > > wrote: > > > > > > Given that 2.12 is so close, my preference would be to limit the scope > > of 2.11.1 to just the log4j update. Would that help bring the > vote/release > > date forward? > > > > > > > On 16 Dec 2021, at 12:44, Maxim Muzafarov wrote: > > > > > > > > Dear Ignite Community! > > > > > > > > I suggest preparing the Apache Ignite 2.11.1 release and I want to > > > > propose myself to be the release manager of the minor release. > > > > > > > > > > > > * RELEASE TIMELINE * > > > > > > > > Scope Freeze: December 16, 2021 > > > > Code Freeze: December 16, 2021 > > > > Voting Date: December 21, 2021 > > > > Release Date: December 24, 2021 > > > > > > > > > > > > * RELEASE SCOPE * > > > > > > > > LOG4J dependency update > > > > https://issues.apache.org/jira/browse/IGNITE-16101 > > > > https://issues.apache.org/jira/browse/IGNITE-16127 > > > > > > > > B+Tree Corrupted exception when using a key extracted from a > > BinaryObject > > > > https://issues.apache.org/jira/browse/IGNITE-12911 > > > > > > > > Regression: Ignite node crash(CorruptedTreeException: B+Tree is > > corrupted) > > > > https://issues.apache.org/jira/browse/IGNITE-15943 > > > > > > > > .NET: ClientFailoverSocket sets logger too late, resulting in null > > > > loggers downstream > > > > https://issues.apache.org/jira/browse/IGNITE-14776 > > > > > > > > The iterator of the ClientCacheQueryCursor can be closed during > > serialization. > > > > https://issues.apache.org/jira/browse/IGNITE-15346 > > > > > > > > Possible owners desync when a node is restarted while rebalancing > with > > > > enabled persistence > > > > https://issues.apache.org/jira/browse/IGNITE-15315 > > > > > > > > Thin client: Tx can fail if there are concurrent tx rollbacks by > > timeout > > > > https://issues.apache.org/jira/browse/IGNITE-15732 > > > > > > > > AssertionError: Unexpected rebalance on rebalanced cluster > > > > https://issues.apache.org/jira/browse/IGNITE-15033 > > > > > > > > JmxMetricExporterSpi throws assertion error on a filtered metric > > unregister > > > > https://issues.apache.org/jira/browse/IGNITE-15252 > > > > > > > > ClassNotFoundException on an attempt to invoke service method from > > > > Java ThinClient after a cluster failover > > > > https://issues.apache.org/jira/browse/IGNITE-15256 > > > > > > > > NullPointerException on an attempt to create a Java ThinClient with > > > > BinaryConfiguration > > > > https://issues.apache.org/jira/browse/IGNITE-15138 > > > > > > > > Java thin client: Type name is not cached on client-side for > > > > OptimizerMarshaller types > > > > https://issues.apache.org/jira/browse/IGNITE-15924 > > > > > > > > select count * returns multiple rows > > > > https://issues.apache.org/jira/browse/IGNITE-14120 > > > > > > > > Fix StackOverflowError in case if an exception is suppressed with > > itself > > > > https://issues.apache.org/jira/browse/IGNITE-15716 > > > > > > > > > > > > WDYT? > > > > > > > > >
Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]
Hello, > Given that 2.12 is so close, my preference would be to limit the scope of 2.11.1 to just the log4j update. I agree with Stephen. Apache Ignite 2.11.1 is an emergency release. Using log4j 2.16 instead of 2.14 is a quite small change that only requires a "sanity" check and can be quickly released. A wider release scope requires full testing, IMHO. Thanks, S. чт, 16 дек. 2021 г. в 16:03, Maxim Muzafarov : > I think it is completely possible to move vote/release dates > significantly forward with keeping the scope. I will take a look at > the list of fixed bugs more narrowly and exclude some of them that > require additional verification. > > On Thu, 16 Dec 2021 at 15:55, Stephen Darlington > wrote: > > > > Given that 2.12 is so close, my preference would be to limit the scope > of 2.11.1 to just the log4j update. Would that help bring the vote/release > date forward? > > > > > On 16 Dec 2021, at 12:44, Maxim Muzafarov wrote: > > > > > > Dear Ignite Community! > > > > > > I suggest preparing the Apache Ignite 2.11.1 release and I want to > > > propose myself to be the release manager of the minor release. > > > > > > > > > * RELEASE TIMELINE * > > > > > > Scope Freeze: December 16, 2021 > > > Code Freeze: December 16, 2021 > > > Voting Date: December 21, 2021 > > > Release Date: December 24, 2021 > > > > > > > > > * RELEASE SCOPE * > > > > > > LOG4J dependency update > > > https://issues.apache.org/jira/browse/IGNITE-16101 > > > https://issues.apache.org/jira/browse/IGNITE-16127 > > > > > > B+Tree Corrupted exception when using a key extracted from a > BinaryObject > > > https://issues.apache.org/jira/browse/IGNITE-12911 > > > > > > Regression: Ignite node crash(CorruptedTreeException: B+Tree is > corrupted) > > > https://issues.apache.org/jira/browse/IGNITE-15943 > > > > > > .NET: ClientFailoverSocket sets logger too late, resulting in null > > > loggers downstream > > > https://issues.apache.org/jira/browse/IGNITE-14776 > > > > > > The iterator of the ClientCacheQueryCursor can be closed during > serialization. > > > https://issues.apache.org/jira/browse/IGNITE-15346 > > > > > > Possible owners desync when a node is restarted while rebalancing with > > > enabled persistence > > > https://issues.apache.org/jira/browse/IGNITE-15315 > > > > > > Thin client: Tx can fail if there are concurrent tx rollbacks by > timeout > > > https://issues.apache.org/jira/browse/IGNITE-15732 > > > > > > AssertionError: Unexpected rebalance on rebalanced cluster > > > https://issues.apache.org/jira/browse/IGNITE-15033 > > > > > > JmxMetricExporterSpi throws assertion error on a filtered metric > unregister > > > https://issues.apache.org/jira/browse/IGNITE-15252 > > > > > > ClassNotFoundException on an attempt to invoke service method from > > > Java ThinClient after a cluster failover > > > https://issues.apache.org/jira/browse/IGNITE-15256 > > > > > > NullPointerException on an attempt to create a Java ThinClient with > > > BinaryConfiguration > > > https://issues.apache.org/jira/browse/IGNITE-15138 > > > > > > Java thin client: Type name is not cached on client-side for > > > OptimizerMarshaller types > > > https://issues.apache.org/jira/browse/IGNITE-15924 > > > > > > select count * returns multiple rows > > > https://issues.apache.org/jira/browse/IGNITE-14120 > > > > > > Fix StackOverflowError in case if an exception is suppressed with > itself > > > https://issues.apache.org/jira/browse/IGNITE-15716 > > > > > > > > > WDYT? > > > > >
Re: [DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3
+1 for 2 чт, 16 дек. 2021 г. в 18:50, Pavel Tupitsyn : > Option 2 seems the most sensible. > It translates to/from other languages and should be already familiar to > some developers. > > For example, with nullable checks enabled, C# treats everything as not > null, unless specified otherwise with "?". > Same for other languages where Option/Maybe type is present. Nothing is > null by default. > > On Thu, Dec 16, 2021 at 6:14 PM Alexander Polovtcev < > alexpolovt...@gmail.com> > wrote: > > > Dear Igniters! > > > > I would like to propose a discussion about defining a policy regarding > > where and how to use @Nullable/@NotNull annotations. These annotations > are > > used in conjunction with a static analysis engine (e.g. built in IDEA) > and > > are useful for avoiding null dereferencing and specifying method > contracts. > > > > I can see the following possible options: > > > > 1. *Use both @Nullable and @NotNull annotations everywhere* (i.e. method > > parameters and return types, class fields). Pros: the most robust and > > expressive variant; easy to agree on and specify. Cons: very verbose; may > > lead to code cluttering; > > 2. *Use only @Nullable *for specifying method parameters that accept null > > or class fields that can be null, treating @NotNull as an implicit > default. > > Pros: correlates with the default IDEA settings (with all corresponding > > inspections enabled); not as verbose as option 1, since nullable > parameters > > are quite rare. Cons: less sound and complete, especially when working > with > > third-party libraries that are not annotated, since we cannot apply the > > implicit @NotNull there; > > 3. *Use only @NotNull *and treat @Nullable as an implicit default. Pros: > > less verbose than option 1, better correlates with Java language > semantics > > (since all Java references are nullable). Cons: more verbose than option > 2; > > may be impossible to properly set up the analysis engine or may require > > switching to a different annotation provider that supports jsr-305 > > @ParametersAreNullableByDefault; > > 4. *Do not use @Nullable nor @NotNull*. The most radical option in case > we > > will not be able to agree on any of the above three. No annotations - no > > need for the discussion. > > > > What do you think? Are there any other options out there? I would like to > > collect as many options as possible and organize a vote some time later. > > > > -- > > With regards, > > Aleksandr Polovtcev > > > -- Best regards, Alexei Scherbakov
Re: [DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3
Option 2 seems the most sensible. It translates to/from other languages and should be already familiar to some developers. For example, with nullable checks enabled, C# treats everything as not null, unless specified otherwise with "?". Same for other languages where Option/Maybe type is present. Nothing is null by default. On Thu, Dec 16, 2021 at 6:14 PM Alexander Polovtcev wrote: > Dear Igniters! > > I would like to propose a discussion about defining a policy regarding > where and how to use @Nullable/@NotNull annotations. These annotations are > used in conjunction with a static analysis engine (e.g. built in IDEA) and > are useful for avoiding null dereferencing and specifying method contracts. > > I can see the following possible options: > > 1. *Use both @Nullable and @NotNull annotations everywhere* (i.e. method > parameters and return types, class fields). Pros: the most robust and > expressive variant; easy to agree on and specify. Cons: very verbose; may > lead to code cluttering; > 2. *Use only @Nullable *for specifying method parameters that accept null > or class fields that can be null, treating @NotNull as an implicit default. > Pros: correlates with the default IDEA settings (with all corresponding > inspections enabled); not as verbose as option 1, since nullable parameters > are quite rare. Cons: less sound and complete, especially when working with > third-party libraries that are not annotated, since we cannot apply the > implicit @NotNull there; > 3. *Use only @NotNull *and treat @Nullable as an implicit default. Pros: > less verbose than option 1, better correlates with Java language semantics > (since all Java references are nullable). Cons: more verbose than option 2; > may be impossible to properly set up the analysis engine or may require > switching to a different annotation provider that supports jsr-305 > @ParametersAreNullableByDefault; > 4. *Do not use @Nullable nor @NotNull*. The most radical option in case we > will not be able to agree on any of the above three. No annotations - no > need for the discussion. > > What do you think? Are there any other options out there? I would like to > collect as many options as possible and organize a vote some time later. > > -- > With regards, > Aleksandr Polovtcev >
[DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3
Dear Igniters! I would like to propose a discussion about defining a policy regarding where and how to use @Nullable/@NotNull annotations. These annotations are used in conjunction with a static analysis engine (e.g. built in IDEA) and are useful for avoiding null dereferencing and specifying method contracts. I can see the following possible options: 1. *Use both @Nullable and @NotNull annotations everywhere* (i.e. method parameters and return types, class fields). Pros: the most robust and expressive variant; easy to agree on and specify. Cons: very verbose; may lead to code cluttering; 2. *Use only @Nullable *for specifying method parameters that accept null or class fields that can be null, treating @NotNull as an implicit default. Pros: correlates with the default IDEA settings (with all corresponding inspections enabled); not as verbose as option 1, since nullable parameters are quite rare. Cons: less sound and complete, especially when working with third-party libraries that are not annotated, since we cannot apply the implicit @NotNull there; 3. *Use only @NotNull *and treat @Nullable as an implicit default. Pros: less verbose than option 1, better correlates with Java language semantics (since all Java references are nullable). Cons: more verbose than option 2; may be impossible to properly set up the analysis engine or may require switching to a different annotation provider that supports jsr-305 @ParametersAreNullableByDefault; 4. *Do not use @Nullable nor @NotNull*. The most radical option in case we will not be able to agree on any of the above three. No annotations - no need for the discussion. What do you think? Are there any other options out there? I would like to collect as many options as possible and organize a vote some time later. -- With regards, Aleksandr Polovtcev
Re: [DISCUSSION] Reject join of nodes with different character encodings
Guys, I like the idea with a flag, but for a different purpose. I think it is easy to detect the issue (using the flag) when metastorage was created on a new version with a fixed charset, or on an older version with the user-defined default. Regarding the flag, we can choose a new strategy forcing UTF-8, or fallback to the old one with defaultCharset and print a warning and recommendation in log. Adding any compatibility stuff is absolutely error-prone because if you fail in the middle of restoring process, you will get broken metastorage with keys in different charsets. At this point, there is no way to detect broken keys anymore.
Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]
I think it is completely possible to move vote/release dates significantly forward with keeping the scope. I will take a look at the list of fixed bugs more narrowly and exclude some of them that require additional verification. On Thu, 16 Dec 2021 at 15:55, Stephen Darlington wrote: > > Given that 2.12 is so close, my preference would be to limit the scope of > 2.11.1 to just the log4j update. Would that help bring the vote/release date > forward? > > > On 16 Dec 2021, at 12:44, Maxim Muzafarov wrote: > > > > Dear Ignite Community! > > > > I suggest preparing the Apache Ignite 2.11.1 release and I want to > > propose myself to be the release manager of the minor release. > > > > > > * RELEASE TIMELINE * > > > > Scope Freeze: December 16, 2021 > > Code Freeze: December 16, 2021 > > Voting Date: December 21, 2021 > > Release Date: December 24, 2021 > > > > > > * RELEASE SCOPE * > > > > LOG4J dependency update > > https://issues.apache.org/jira/browse/IGNITE-16101 > > https://issues.apache.org/jira/browse/IGNITE-16127 > > > > B+Tree Corrupted exception when using a key extracted from a BinaryObject > > https://issues.apache.org/jira/browse/IGNITE-12911 > > > > Regression: Ignite node crash(CorruptedTreeException: B+Tree is corrupted) > > https://issues.apache.org/jira/browse/IGNITE-15943 > > > > .NET: ClientFailoverSocket sets logger too late, resulting in null > > loggers downstream > > https://issues.apache.org/jira/browse/IGNITE-14776 > > > > The iterator of the ClientCacheQueryCursor can be closed during > > serialization. > > https://issues.apache.org/jira/browse/IGNITE-15346 > > > > Possible owners desync when a node is restarted while rebalancing with > > enabled persistence > > https://issues.apache.org/jira/browse/IGNITE-15315 > > > > Thin client: Tx can fail if there are concurrent tx rollbacks by timeout > > https://issues.apache.org/jira/browse/IGNITE-15732 > > > > AssertionError: Unexpected rebalance on rebalanced cluster > > https://issues.apache.org/jira/browse/IGNITE-15033 > > > > JmxMetricExporterSpi throws assertion error on a filtered metric unregister > > https://issues.apache.org/jira/browse/IGNITE-15252 > > > > ClassNotFoundException on an attempt to invoke service method from > > Java ThinClient after a cluster failover > > https://issues.apache.org/jira/browse/IGNITE-15256 > > > > NullPointerException on an attempt to create a Java ThinClient with > > BinaryConfiguration > > https://issues.apache.org/jira/browse/IGNITE-15138 > > > > Java thin client: Type name is not cached on client-side for > > OptimizerMarshaller types > > https://issues.apache.org/jira/browse/IGNITE-15924 > > > > select count * returns multiple rows > > https://issues.apache.org/jira/browse/IGNITE-14120 > > > > Fix StackOverflowError in case if an exception is suppressed with itself > > https://issues.apache.org/jira/browse/IGNITE-15716 > > > > > > WDYT? > >
Re: [DISCUSS] Custom service proxy context
Pavel, My vote is for option (1). Simple and clear. As you noted, with (2) it is not clear which methods are affected. Also, we don't provide methods like withTimeout, withSticky, so adding withContext will introduce another inconsistency. (3) seems to be too complicated. On Thu, Dec 16, 2021 at 3:34 PM Pavel Pereslegin wrote: > Hi folks! > > The discussed feature is currently under development and recently > there was a proposal for an API improvement, which I want to discuss. > > It is about how the user can specify a service call context when > getting a proxy. > > I see the following options: > > 1. Passing the context as an argument to the proxy getter method. > >Ignite.services().serviceProxy(name,..., callCtx) > >The disadvantage is that for ease of use, we add several >overloads of this method with different combinations of parameters. > > 2. Adding a new method "withCallContext(callCtx)" (returns > IgniteServices) to the IgniteServices interface. > >Ignite.services().withCallContext(callCtx).serviceProxy(name,...) > >The disadvantage is that most of the IgniteServices methods >are not related to the service call context (deploy, cancel >of the service, etc.). > > 3. (extension of the 2nd option) Adding a new > "withCallContext(callCtx)" method which returns a new interface. > >Ignite.service().withCallContext(callCtx).serviceProxy(name,...) > >Unlike the 2nd option, the "withCallContext()" method returns a new > interface >(for example, IgniteServiceProxies or IgniteContextAwareServices), which >contains only methods that use the service call context. > > WDYT? > > пт, 22 окт. 2021 г. в 14:36, Pavel Pereslegin : > > > > > 1. Add init/execute/cancel methods without parameters. > > > 2. Add default no-op implementations for the new methods (this is > required > > > to preserve compatibility). > > > 3. For old methods that take ServiceContext as a parameter, add default > > > implementations that delegate to new methods. > > > 4. Deprecate the old methods on the API. > > > 5. On the implementation level, still use the old methods (again - for > > > compatibility). > > > 6. Finally, add a @ServiceContextResource annotation to inject > > > ServiceContext. > > > > I like this idea and I have filed a ticket for this change [1]. > > If there is no objection, I plan to implement this shortly. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15801 > > > > ср, 20 окт. 2021 г. в 08:54, Nikolay Izhikov : > > > > > > > and it fully switches to annotation-based injection. > > > > > > +1 to do it. > > > > > > > 19 окт. 2021 г., в 22:14, Valentin Kulichenko < > valentin.kuliche...@gmail.com> написал(а): > > > > > > > > That's actually a good point. In Java, we can do the following: > > > > 1. Add init/execute/cancel methods without parameters. > > > > 2. Add default no-op implementations for the new methods (this is > required > > > > to preserve compatibility). > > > > 3. For old methods that take ServiceContext as a parameter, add > default > > > > implementations that delegate to new methods. > > > > 4. Deprecate the old methods on the API. > > > > 5. On the implementation level, still use the old methods (again - > for > > > > compatibility). > > > > 6. Finally, add a @ServiceContextResource annotation to inject > > > > ServiceContext. > > > > > > > > If I haven't missed anything, this is not a breaking change, and it > fully > > > > switches to annotation-based injection. > > > > > > > > I'm not sure this is possible in .NET though. > > > > > > > > -Val > > > > > > > > On Tue, Oct 19, 2021 at 11:47 AM Pavel Pereslegin > wrote: > > > > > > > >>> Removing parameters from a public interface method is a breaking > change, > > > >>> or do you mean something else? > > > >> > > > >> Sorry, I meant that we can inject the service context, but leave it > > > >> available in the init/execute/cancel methods and add a default > "no-op" > > > >> implementation in the interface for them. Can we do this? > > > >> > > > >>> Regarding .NET - let's have a separate ticket for that? > > > >> If we decide to "inject" a service context - this should be done in > a > > > >> separate ticket. > > > >> If you are talking about "proxy service context" - I can split it > into > > > >> 3 parts (java, Net, and thin clients) > > > >> > > > >> вт, 19 окт. 2021 г. в 21:23, Pavel Tupitsyn : > > > >>> > > > >>> Pavel, > > > >>> > > > From my point of view, this should not break anything > > > >>> Removing parameters from a public interface method is a breaking > change, > > > >>> or do you mean something else? > > > >>> > > > >>> Regarding .NET - let's have a separate ticket for that? > > > >>> We can discuss and implement Java changes first. > > > >>> > > > >>> On Tue, Oct 19, 2021 at 8:27 PM Pavel Pereslegin > > > > >> wrote: > > > >>> > > > Thanks a lot for your suggestions. > > > > > > > We might consider injecting the ServiceContext instead of > passing it > >
Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]
Folks, This is also a good candidate to include in the proposed release. AssertionError in B+Tree under load https://issues.apache.org/jira/browse/IGNITE-15990 On Thu, 16 Dec 2021 at 15:54, Pavel Tupitsyn wrote: > > Maxim, > > Thanks for taking this, scope looks good to me. > I think we can even start the vote today or tomorrow, given the severity of > log4j issue. > > Pavel > > On Thu, Dec 16, 2021 at 3:44 PM Maxim Muzafarov wrote: > > > Dear Ignite Community! > > > > I suggest preparing the Apache Ignite 2.11.1 release and I want to > > propose myself to be the release manager of the minor release. > > > > > > * RELEASE TIMELINE * > > > > Scope Freeze: December 16, 2021 > > Code Freeze: December 16, 2021 > > Voting Date: December 21, 2021 > > Release Date: December 24, 2021 > > > > > > * RELEASE SCOPE * > > > > LOG4J dependency update > > https://issues.apache.org/jira/browse/IGNITE-16101 > > https://issues.apache.org/jira/browse/IGNITE-16127 > > > > B+Tree Corrupted exception when using a key extracted from a BinaryObject > > https://issues.apache.org/jira/browse/IGNITE-12911 > > > > Regression: Ignite node crash(CorruptedTreeException: B+Tree is corrupted) > > https://issues.apache.org/jira/browse/IGNITE-15943 > > > > .NET: ClientFailoverSocket sets logger too late, resulting in null > > loggers downstream > > https://issues.apache.org/jira/browse/IGNITE-14776 > > > > The iterator of the ClientCacheQueryCursor can be closed during > > serialization. > > https://issues.apache.org/jira/browse/IGNITE-15346 > > > > Possible owners desync when a node is restarted while rebalancing with > > enabled persistence > > https://issues.apache.org/jira/browse/IGNITE-15315 > > > > Thin client: Tx can fail if there are concurrent tx rollbacks by timeout > > https://issues.apache.org/jira/browse/IGNITE-15732 > > > > AssertionError: Unexpected rebalance on rebalanced cluster > > https://issues.apache.org/jira/browse/IGNITE-15033 > > > > JmxMetricExporterSpi throws assertion error on a filtered metric unregister > > https://issues.apache.org/jira/browse/IGNITE-15252 > > > > ClassNotFoundException on an attempt to invoke service method from > > Java ThinClient after a cluster failover > > https://issues.apache.org/jira/browse/IGNITE-15256 > > > > NullPointerException on an attempt to create a Java ThinClient with > > BinaryConfiguration > > https://issues.apache.org/jira/browse/IGNITE-15138 > > > > Java thin client: Type name is not cached on client-side for > > OptimizerMarshaller types > > https://issues.apache.org/jira/browse/IGNITE-15924 > > > > select count * returns multiple rows > > https://issues.apache.org/jira/browse/IGNITE-14120 > > > > Fix StackOverflowError in case if an exception is suppressed with itself > > https://issues.apache.org/jira/browse/IGNITE-15716 > > > > > > WDYT? > >
Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]
Given that 2.12 is so close, my preference would be to limit the scope of 2.11.1 to just the log4j update. Would that help bring the vote/release date forward? > On 16 Dec 2021, at 12:44, Maxim Muzafarov wrote: > > Dear Ignite Community! > > I suggest preparing the Apache Ignite 2.11.1 release and I want to > propose myself to be the release manager of the minor release. > > > * RELEASE TIMELINE * > > Scope Freeze: December 16, 2021 > Code Freeze: December 16, 2021 > Voting Date: December 21, 2021 > Release Date: December 24, 2021 > > > * RELEASE SCOPE * > > LOG4J dependency update > https://issues.apache.org/jira/browse/IGNITE-16101 > https://issues.apache.org/jira/browse/IGNITE-16127 > > B+Tree Corrupted exception when using a key extracted from a BinaryObject > https://issues.apache.org/jira/browse/IGNITE-12911 > > Regression: Ignite node crash(CorruptedTreeException: B+Tree is corrupted) > https://issues.apache.org/jira/browse/IGNITE-15943 > > .NET: ClientFailoverSocket sets logger too late, resulting in null > loggers downstream > https://issues.apache.org/jira/browse/IGNITE-14776 > > The iterator of the ClientCacheQueryCursor can be closed during serialization. > https://issues.apache.org/jira/browse/IGNITE-15346 > > Possible owners desync when a node is restarted while rebalancing with > enabled persistence > https://issues.apache.org/jira/browse/IGNITE-15315 > > Thin client: Tx can fail if there are concurrent tx rollbacks by timeout > https://issues.apache.org/jira/browse/IGNITE-15732 > > AssertionError: Unexpected rebalance on rebalanced cluster > https://issues.apache.org/jira/browse/IGNITE-15033 > > JmxMetricExporterSpi throws assertion error on a filtered metric unregister > https://issues.apache.org/jira/browse/IGNITE-15252 > > ClassNotFoundException on an attempt to invoke service method from > Java ThinClient after a cluster failover > https://issues.apache.org/jira/browse/IGNITE-15256 > > NullPointerException on an attempt to create a Java ThinClient with > BinaryConfiguration > https://issues.apache.org/jira/browse/IGNITE-15138 > > Java thin client: Type name is not cached on client-side for > OptimizerMarshaller types > https://issues.apache.org/jira/browse/IGNITE-15924 > > select count * returns multiple rows > https://issues.apache.org/jira/browse/IGNITE-14120 > > Fix StackOverflowError in case if an exception is suppressed with itself > https://issues.apache.org/jira/browse/IGNITE-15716 > > > WDYT?
Re: Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]
Maxim, Thanks for taking this, scope looks good to me. I think we can even start the vote today or tomorrow, given the severity of log4j issue. Pavel On Thu, Dec 16, 2021 at 3:44 PM Maxim Muzafarov wrote: > Dear Ignite Community! > > I suggest preparing the Apache Ignite 2.11.1 release and I want to > propose myself to be the release manager of the minor release. > > > * RELEASE TIMELINE * > > Scope Freeze: December 16, 2021 > Code Freeze: December 16, 2021 > Voting Date: December 21, 2021 > Release Date: December 24, 2021 > > > * RELEASE SCOPE * > > LOG4J dependency update > https://issues.apache.org/jira/browse/IGNITE-16101 > https://issues.apache.org/jira/browse/IGNITE-16127 > > B+Tree Corrupted exception when using a key extracted from a BinaryObject > https://issues.apache.org/jira/browse/IGNITE-12911 > > Regression: Ignite node crash(CorruptedTreeException: B+Tree is corrupted) > https://issues.apache.org/jira/browse/IGNITE-15943 > > .NET: ClientFailoverSocket sets logger too late, resulting in null > loggers downstream > https://issues.apache.org/jira/browse/IGNITE-14776 > > The iterator of the ClientCacheQueryCursor can be closed during > serialization. > https://issues.apache.org/jira/browse/IGNITE-15346 > > Possible owners desync when a node is restarted while rebalancing with > enabled persistence > https://issues.apache.org/jira/browse/IGNITE-15315 > > Thin client: Tx can fail if there are concurrent tx rollbacks by timeout > https://issues.apache.org/jira/browse/IGNITE-15732 > > AssertionError: Unexpected rebalance on rebalanced cluster > https://issues.apache.org/jira/browse/IGNITE-15033 > > JmxMetricExporterSpi throws assertion error on a filtered metric unregister > https://issues.apache.org/jira/browse/IGNITE-15252 > > ClassNotFoundException on an attempt to invoke service method from > Java ThinClient after a cluster failover > https://issues.apache.org/jira/browse/IGNITE-15256 > > NullPointerException on an attempt to create a Java ThinClient with > BinaryConfiguration > https://issues.apache.org/jira/browse/IGNITE-15138 > > Java thin client: Type name is not cached on client-side for > OptimizerMarshaller types > https://issues.apache.org/jira/browse/IGNITE-15924 > > select count * returns multiple rows > https://issues.apache.org/jira/browse/IGNITE-14120 > > Fix StackOverflowError in case if an exception is suppressed with itself > https://issues.apache.org/jira/browse/IGNITE-15716 > > > WDYT? >
Apache Ignite 2.11.1 RELEASE [Time, Scope, Manager]
Dear Ignite Community! I suggest preparing the Apache Ignite 2.11.1 release and I want to propose myself to be the release manager of the minor release. * RELEASE TIMELINE * Scope Freeze: December 16, 2021 Code Freeze: December 16, 2021 Voting Date: December 21, 2021 Release Date: December 24, 2021 * RELEASE SCOPE * LOG4J dependency update https://issues.apache.org/jira/browse/IGNITE-16101 https://issues.apache.org/jira/browse/IGNITE-16127 B+Tree Corrupted exception when using a key extracted from a BinaryObject https://issues.apache.org/jira/browse/IGNITE-12911 Regression: Ignite node crash(CorruptedTreeException: B+Tree is corrupted) https://issues.apache.org/jira/browse/IGNITE-15943 .NET: ClientFailoverSocket sets logger too late, resulting in null loggers downstream https://issues.apache.org/jira/browse/IGNITE-14776 The iterator of the ClientCacheQueryCursor can be closed during serialization. https://issues.apache.org/jira/browse/IGNITE-15346 Possible owners desync when a node is restarted while rebalancing with enabled persistence https://issues.apache.org/jira/browse/IGNITE-15315 Thin client: Tx can fail if there are concurrent tx rollbacks by timeout https://issues.apache.org/jira/browse/IGNITE-15732 AssertionError: Unexpected rebalance on rebalanced cluster https://issues.apache.org/jira/browse/IGNITE-15033 JmxMetricExporterSpi throws assertion error on a filtered metric unregister https://issues.apache.org/jira/browse/IGNITE-15252 ClassNotFoundException on an attempt to invoke service method from Java ThinClient after a cluster failover https://issues.apache.org/jira/browse/IGNITE-15256 NullPointerException on an attempt to create a Java ThinClient with BinaryConfiguration https://issues.apache.org/jira/browse/IGNITE-15138 Java thin client: Type name is not cached on client-side for OptimizerMarshaller types https://issues.apache.org/jira/browse/IGNITE-15924 select count * returns multiple rows https://issues.apache.org/jira/browse/IGNITE-14120 Fix StackOverflowError in case if an exception is suppressed with itself https://issues.apache.org/jira/browse/IGNITE-15716 WDYT?
Re: [DISCUSS] Custom service proxy context
Hi folks! The discussed feature is currently under development and recently there was a proposal for an API improvement, which I want to discuss. It is about how the user can specify a service call context when getting a proxy. I see the following options: 1. Passing the context as an argument to the proxy getter method. Ignite.services().serviceProxy(name,..., callCtx) The disadvantage is that for ease of use, we add several overloads of this method with different combinations of parameters. 2. Adding a new method "withCallContext(callCtx)" (returns IgniteServices) to the IgniteServices interface. Ignite.services().withCallContext(callCtx).serviceProxy(name,...) The disadvantage is that most of the IgniteServices methods are not related to the service call context (deploy, cancel of the service, etc.). 3. (extension of the 2nd option) Adding a new "withCallContext(callCtx)" method which returns a new interface. Ignite.service().withCallContext(callCtx).serviceProxy(name,...) Unlike the 2nd option, the "withCallContext()" method returns a new interface (for example, IgniteServiceProxies or IgniteContextAwareServices), which contains only methods that use the service call context. WDYT? пт, 22 окт. 2021 г. в 14:36, Pavel Pereslegin : > > > 1. Add init/execute/cancel methods without parameters. > > 2. Add default no-op implementations for the new methods (this is required > > to preserve compatibility). > > 3. For old methods that take ServiceContext as a parameter, add default > > implementations that delegate to new methods. > > 4. Deprecate the old methods on the API. > > 5. On the implementation level, still use the old methods (again - for > > compatibility). > > 6. Finally, add a @ServiceContextResource annotation to inject > > ServiceContext. > > I like this idea and I have filed a ticket for this change [1]. > If there is no objection, I plan to implement this shortly. > > [1] https://issues.apache.org/jira/browse/IGNITE-15801 > > ср, 20 окт. 2021 г. в 08:54, Nikolay Izhikov : > > > > > and it fully switches to annotation-based injection. > > > > +1 to do it. > > > > > 19 окт. 2021 г., в 22:14, Valentin Kulichenko > > > написал(а): > > > > > > That's actually a good point. In Java, we can do the following: > > > 1. Add init/execute/cancel methods without parameters. > > > 2. Add default no-op implementations for the new methods (this is required > > > to preserve compatibility). > > > 3. For old methods that take ServiceContext as a parameter, add default > > > implementations that delegate to new methods. > > > 4. Deprecate the old methods on the API. > > > 5. On the implementation level, still use the old methods (again - for > > > compatibility). > > > 6. Finally, add a @ServiceContextResource annotation to inject > > > ServiceContext. > > > > > > If I haven't missed anything, this is not a breaking change, and it fully > > > switches to annotation-based injection. > > > > > > I'm not sure this is possible in .NET though. > > > > > > -Val > > > > > > On Tue, Oct 19, 2021 at 11:47 AM Pavel Pereslegin > > > wrote: > > > > > >>> Removing parameters from a public interface method is a breaking change, > > >>> or do you mean something else? > > >> > > >> Sorry, I meant that we can inject the service context, but leave it > > >> available in the init/execute/cancel methods and add a default "no-op" > > >> implementation in the interface for them. Can we do this? > > >> > > >>> Regarding .NET - let's have a separate ticket for that? > > >> If we decide to "inject" a service context - this should be done in a > > >> separate ticket. > > >> If you are talking about "proxy service context" - I can split it into > > >> 3 parts (java, Net, and thin clients) > > >> > > >> вт, 19 окт. 2021 г. в 21:23, Pavel Tupitsyn : > > >>> > > >>> Pavel, > > >>> > > From my point of view, this should not break anything > > >>> Removing parameters from a public interface method is a breaking change, > > >>> or do you mean something else? > > >>> > > >>> Regarding .NET - let's have a separate ticket for that? > > >>> We can discuss and implement Java changes first. > > >>> > > >>> On Tue, Oct 19, 2021 at 8:27 PM Pavel Pereslegin > > >> wrote: > > >>> > > Thanks a lot for your suggestions. > > > > > We might consider injecting the ServiceContext instead of passing it > > >> to > > > IgniteService methods, but I believe this will be a breaking change? > > > > From my point of view, this should not break anything. We can inject a > > service context when initializing a service and keep it accessible in > > state transition methods (init/execute/cancel). > > Currently, in .Net ServiceContext doesn't share the same instance, but > > this can be reworked - for example, we can store the service context > > (with a reference to the service) in the resource registry instead of > > the service itself. > > > > But
Re: [DISCUSSION] Reject join of nodes with different character encodings
Slava, great ticket! I suppose, that we can add feature flag to BPlusMetaIO and if it doesn't present or it is value is false, we can rebuild metastore during recovery and decode strings to default system encoding and save all of them back to UTF-8. After recovery, we should use UTF-8 by default. чт, 16 дек. 2021 г. в 13:35, Вячеслав Коптилин : > Hi folks, > > IMHO, we should do our best to fix all these places and should avoid using > the default charset. In my understanding, this is only > > > The main question is - should we restrict the join of nodes with > different encodings or just fix all places where implicit default encoding > is used and specify the explicit one as Ivan Daschinsky suggested? > Restricting the join of nodes is not a solution for all cases. You are in > trouble even though you use a one-node cluster. Just change the default > charset on your system and restart the node with existing PDS [1] > > > As for me, I'm expecting a way more problem with enforcing rule to fail, > rather than enforcing all components to use UTF-8 > Absolutely agree with Ivan. > > [1] https://issues.apache.org/jira/browse/IGNITE-16080 > > Thanks, > S. > > вт, 14 дек. 2021 г. в 10:52, Ivan Pavlukhin : > > > Do encodings in question somehow influence on actual stored data > > (bytes)? If so, using an implicit platform encoding sounds quite > > dangerous. Moving data between servers (or perhaps even rebalancing) > > can lead to bad consequences. Anyways, IMHO an implicit encoding is > > not good, but sensible default is quite robust. > > > > 2021-12-13 23:07 GMT+03:00, Ivan Daschinsky : > > > Unpaited surrogates are emoji symbols. One should be completely insane > to > > > use emojis in login. > > > > > > пн, 13 дек. 2021 г., 21:30 Mikhail Petrov : > > > > > >> Ivan, string with unpaired surrogates symbols are serialized and > > >> deserialized by java UTF-8 decoder successfully but the result does > not > > >> match the initial string. It may result in that if the user's login > > >> contains these symbols, it will be distorted after deserialization and > > >> the user will not be able to log in. I understand that it is a quite > > >> rare case. > > >> Anyway, the way to solve this problem was introduced here - > > >> https://issues.apache.org/jira/browse/IGNITE-3098 > > >> > > >> Frankly, it is not the topic I would like to discuss now. The main > > >> question is - should we restrict the join of nodes with different > > >> encodings or just fix all places where implicit default encoding is > used > > >> and specify the explicit one as Ivan Daschinsky suggested? > > >> > > >> From my point of view, it is better to reject nodes with different > > >> encodings (especially after Ilya Kasnacheev mentioned that we already > > >> have a warning "Differing character encodings across cluster may lead > > >> to erratic behavior"). It will help to avoid "erratic behavior", not > > >> just warn about it. It is important since the problems related to > string > > >> encoding can occur in different components and the cause of them is > not > > >> always obvious. > > >> > > >> WDYT? > > >> > > >> On 13.12.2021 20:01, Ivan Pavlukhin wrote: > > >> >> I guess Nikolay is talking about the problem with UTF-8 in case > > string > > >> contains unpaired surrogate symbols > > >> > Folks, give me a clue why it is a problem? Naively it seems to be a > > >> > good restriction rather than problem. What problems can it cause in > > >> > practice? > > >> > > > >> > 2021-12-13 16:32 GMT+03:00, Ilya Kasnacheev > > >> > : > > >> >> Hello! > > >> >> > > >> >> We already have a warning about this, see > > >> IgniteKernal.checkFileEncoding() > > >> >> > > >> >> Regards, > > >> >> -- > > >> >> Ilya Kasnacheev > > >> >> > > >> >> > > >> >> пн, 13 дек. 2021 г. в 16:26, Ivan Daschinsky >: > > >> >> > > >> > But now multiple components > > >> > independently serialize strings for their needs and use default > > >> > encoding > > >> > for this. > > >> > For example DirectByteBufferStreamImplV2#writeString, > > >> > MetaStorage#writeRaw and so on > > >> >>> We should fix all of them. > > >> >>> > > >> > BinaryUtils#utf8BytesToStr > > >> >>> Lets use this everywhere. > > >> >>> > > >> >>> As for me, I'm expecting a way more problem with enforcing rule to > > >> fail, > > >> >>> rather than enforcing all components to use UTF-8 > > >> >>> Some weird cases (surrogate pairs) we can (I strongly believe it > is > > >> OK) > > >> >>> simply do not consider at all. > > >> >>> > > >> >>> пн, 13 дек. 2021 г. в 15:15, Nikolay Izhikov >: > > >> >>> > > >> > Does Java String support all unicode characters and particularly > > >> > does > > >> >>> it > > >> support more characters than UTF-8 > > >> > > >> It’s not about Java, it’s about UTF-8 standard. > > >> > > >> Please, take a look at [1] > > >> > > >> > In November 2003, UTF-8 was restricted by RFC 3629 to match the > > >>
Re: [DISCUSSION] Reject join of nodes with different character encodings
Hi folks, IMHO, we should do our best to fix all these places and should avoid using the default charset. In my understanding, this is only > The main question is - should we restrict the join of nodes with different encodings or just fix all places where implicit default encoding is used and specify the explicit one as Ivan Daschinsky suggested? Restricting the join of nodes is not a solution for all cases. You are in trouble even though you use a one-node cluster. Just change the default charset on your system and restart the node with existing PDS [1] > As for me, I'm expecting a way more problem with enforcing rule to fail, rather than enforcing all components to use UTF-8 Absolutely agree with Ivan. [1] https://issues.apache.org/jira/browse/IGNITE-16080 Thanks, S. вт, 14 дек. 2021 г. в 10:52, Ivan Pavlukhin : > Do encodings in question somehow influence on actual stored data > (bytes)? If so, using an implicit platform encoding sounds quite > dangerous. Moving data between servers (or perhaps even rebalancing) > can lead to bad consequences. Anyways, IMHO an implicit encoding is > not good, but sensible default is quite robust. > > 2021-12-13 23:07 GMT+03:00, Ivan Daschinsky : > > Unpaited surrogates are emoji symbols. One should be completely insane to > > use emojis in login. > > > > пн, 13 дек. 2021 г., 21:30 Mikhail Petrov : > > > >> Ivan, string with unpaired surrogates symbols are serialized and > >> deserialized by java UTF-8 decoder successfully but the result does not > >> match the initial string. It may result in that if the user's login > >> contains these symbols, it will be distorted after deserialization and > >> the user will not be able to log in. I understand that it is a quite > >> rare case. > >> Anyway, the way to solve this problem was introduced here - > >> https://issues.apache.org/jira/browse/IGNITE-3098 > >> > >> Frankly, it is not the topic I would like to discuss now. The main > >> question is - should we restrict the join of nodes with different > >> encodings or just fix all places where implicit default encoding is used > >> and specify the explicit one as Ivan Daschinsky suggested? > >> > >> From my point of view, it is better to reject nodes with different > >> encodings (especially after Ilya Kasnacheev mentioned that we already > >> have a warning "Differing character encodings across cluster may lead > >> to erratic behavior"). It will help to avoid "erratic behavior", not > >> just warn about it. It is important since the problems related to string > >> encoding can occur in different components and the cause of them is not > >> always obvious. > >> > >> WDYT? > >> > >> On 13.12.2021 20:01, Ivan Pavlukhin wrote: > >> >> I guess Nikolay is talking about the problem with UTF-8 in case > string > >> contains unpaired surrogate symbols > >> > Folks, give me a clue why it is a problem? Naively it seems to be a > >> > good restriction rather than problem. What problems can it cause in > >> > practice? > >> > > >> > 2021-12-13 16:32 GMT+03:00, Ilya Kasnacheev > >> > : > >> >> Hello! > >> >> > >> >> We already have a warning about this, see > >> IgniteKernal.checkFileEncoding() > >> >> > >> >> Regards, > >> >> -- > >> >> Ilya Kasnacheev > >> >> > >> >> > >> >> пн, 13 дек. 2021 г. в 16:26, Ivan Daschinsky : > >> >> > >> > But now multiple components > >> > independently serialize strings for their needs and use default > >> > encoding > >> > for this. > >> > For example DirectByteBufferStreamImplV2#writeString, > >> > MetaStorage#writeRaw and so on > >> >>> We should fix all of them. > >> >>> > >> > BinaryUtils#utf8BytesToStr > >> >>> Lets use this everywhere. > >> >>> > >> >>> As for me, I'm expecting a way more problem with enforcing rule to > >> fail, > >> >>> rather than enforcing all components to use UTF-8 > >> >>> Some weird cases (surrogate pairs) we can (I strongly believe it is > >> OK) > >> >>> simply do not consider at all. > >> >>> > >> >>> пн, 13 дек. 2021 г. в 15:15, Nikolay Izhikov : > >> >>> > >> > Does Java String support all unicode characters and particularly > >> > does > >> >>> it > >> support more characters than UTF-8 > >> > >> It’s not about Java, it’s about UTF-8 standard. > >> > >> Please, take a look at [1] > >> > >> > In November 2003, UTF-8 was restricted by RFC 3629 to match the > >> constraints of the UTF-16 character encoding: explicitly > prohibiting > >> code > >> points corresponding to the high and low surrogate characters > >> removed > >> >>> more > >> than 3% of the three-byte sequences, and ending at U+10 removed > >> more > >> than 48% of the four-byte sequences and all five- and six-byte > >> sequences. > >> > >> And [2] > >> > >> > The definition of UTF-8 prohibits encoding character numbers > >> > between > >> U+D800 and U+DFFF, which are reserved for use with the UTF-16 > >>
Re: Apache Ignite 2.12 RELEASE [Time, Scope, Manager]
Hello Nikita, > I have cherry-picked the issue [1] to the 2.12. It updates the log4j version to 2.16. Thanks a lot! Could you please share a current timeline for the rest steps related to the release? Thanks, S. ср, 15 дек. 2021 г. в 21:45, Nikita Amelchev : > I have cherry-picked the issue [1] to the 2.12. It updates the log4j > version to 2.16. > > Slava, thank you. > > [1] https://issues.apache.org/jira/browse/IGNITE-16127 > > ср, 15 дек. 2021 г. в 14:14, Вячеслав Коптилин : > > > > Hello, > > > > Nikita, it seems that we have to add the following ticket > > https://issues.apache.org/jira/browse/IGNITE-16127 to Apache Ignite 2.12 > > release. > > > > Thanks, > > S. > > > > > > вт, 14 дек. 2021 г. в 09:54, Nikita Amelchev : > > > > > +1 to move these auth issues to the next release. I will prepare RC at > > > the nearest time. > > > > > > пн, 13 дек. 2021 г. в 16:13, Pavel Tupitsyn : > > > > > > > > Agree with Nikolay, let's proceed with the release. > > > > > > > > On Mon, Dec 13, 2021 at 3:31 PM Nikolay Izhikov > > > > wrote: > > > > > > > > > Nikita. > > > > > > > > > > I don’t think IGNITE-16068 is a release blocker. > > > > > > > > > > 1. It only happens when authentication enabled. > > > > > 2. There is at lease 2 workarounds: > > > > > a. Use the same file.encoding for all Ignite nodes. > > > > > b. Use only latin characters in user login. > > > > > > > > > > I propose to postpone this ticket and move on with the release. > > > > > > > > > > > 13 дек. 2021 г., в 15:28, Nikita Amelchev > > > > > написал(а): > > > > > > > > > > > > Hello. > > > > > > > > > > > > I have cherry-picked the blocked [1] to the 2.12. It updates the > > > log4j > > > > > > version to 2.15. > > > > > > > > > > > > The release is blocked by one blocker issue with auth. > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-16101 > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-16068 > > > > > > > > > > > > чт, 9 дек. 2021 г. в 12:44, Nikita Amelchev < > namelc...@apache.org>: > > > > > >> > > > > > >> Hello, Nikolay. > > > > > >> > > > > > >> I have cherry-picked the issue fix. > > > > > >> > > > > > >> Thank you. > > > > > >> > > > > > >> ср, 8 дек. 2021 г. в 18:47, Nikolay Izhikov < > nizhi...@apache.org>: > > > > > >>> > > > > > >>> Hello. > > > > > >>> > > > > > >>> Let’s include [1] in 2.12 scope. > > > > > >>> > > > > > >>> After migrations authentication processor to security API we > have > > > an > > > > > issue. > > > > > >>> Persistent data region should exists on client node if > > > authentication > > > > > is enabled. > > > > > >>> > > > > > >>> It seems very annoying for the users. > > > > > >>> > > > > > >>> [1] https://issues.apache.org/jira/browse/IGNITE-15969 > > > > > >>> > > > > > 2 дек. 2021 г., в 19:50, Nikita Amelchev < > namelc...@apache.org> > > > > > написал(а): > > > > > > > > > > I would like to formally announce code freeze for 2.12.0. Only > > > > > blockers are accepted to be included to the scope. [1] > > > > > > > > > > We have one blocker issue [2] that will be fixed soon. > > > > > > > > > > [1] > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P3.Stabilization > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-15966 > > > > > > > > > > чт, 2 дек. 2021 г. в 16:01, Nikita Amelchev < > namelc...@apache.org > > > >: > > > > > > > > > > > > Hi, Igniters. > > > > > > > > > > > > The release is blocked by the auth issue [1] discussed > above. The > > > > > > patch will be prepared at the nearest time. > > > > > > > > > > > > I want to include the useful issue that adds the ability to > > > configure > > > > > > snapshot thread pool size if nobody minds. > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15966 > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-16014 > > > > > > > > > > > > пт, 26 нояб. 2021 г. в 11:44, Nikita Amelchev < > > > namelc...@apache.org > > > > > >: > > > > > >> > > > > > >> Hello, > > > > > >> > > > > > >> I want to include the issue [1] to the 2.12 scope. It fixes > some > > > > > >> metrics according to the JSR107. > > > > > >> > > > > > >> Any objections? > > > > > >> > > > > > >> [1] https://issues.apache.org/jira/browse/IGNITE-16002 The > > > remove > > > > > >> cache method should update statistics if the method returns > true > > > > > >> > > > > > >> чт, 25 нояб. 2021 г. в 17:12, Nikita Amelchev < > > > namelc...@apache.org > > > > > >: > > > > > >>> > > > > > >>> Hello Ivan, > > > > > >>> > > > > > >>> +1, the issue can be cherry-picked to the 2.12. > > > > > >>> > > > > > >>> чт, 25 нояб. 2021 г. в 17:07, Ivan Bessonov < > > > bessonov...@gmail.com > > > > > >: > > > > > > > > > > Hello everyone, > > > > > > > > > >
