Re: IEP-83 Thin Client Keepalive (heartbeat)
I've prepared a PR, please have a look: https://github.com/apache/ignite/pull/9817 On Mon, Feb 7, 2022 at 6:37 PM Ivan Daschinsky wrote: > I see potential in this feature, especially if we use something like > continuous query. Stale clients can consume a lot of resources and it is > worth kick these clients out. > > пн, 7 февр. 2022 г. в 18:25, Pavel Tupitsyn : > > > > If we use new approach, we can reduce this timeout. But this can affect > > old clients. > > > > idleTimeout is disabled by default, we are not going to change this. > > > > > Also, let's think about that sending heartbeats and interval of sending > > > heartbeats could be calculated on the server side (i.e. one third of > idle > > > timeout) and sent to the client during handshake. > > > Also we can introduce something like a negotiation mechanism as in > > > zookeeper. > > > > I tend to agree with Maksim here, let's keep it simple and explicit. > > Log a warning, but don't do anything clever. > > > > On Mon, Feb 7, 2022 at 6:15 PM Ivan Daschinsky > > wrote: > > > > > >> idleTimeout already exists, I don't think we should change the way > it > > > works (or did I misunderstand you?) > > > If we use new approach, we can reduce this timeout. But this can affect > > old > > > clients. > > > > > > > > > Also, let's think about that sending heartbeats and interval of sending > > > heartbeats could be calculated on the server side (i.e. one third of > idle > > > timeout) and sent to the client > > > during handshake. > > > Also we can introduce something like a negotiation mechanism as in > > > zookeeper. > > > > > > > > > пн, 7 февр. 2022 г. в 18:05, Pavel Tupitsyn : > > > > > > > Igor, > > > > > > > > > Maybe clients should pass this information on to the handshake. > > > > > > > > Do you think we should log a mismatched timeout warning on the > server, > > > not > > > > on the client? > > > > Or should we do both? > > > > > > > > > > > > I've updated the proposal with OP_GET_IDLE_TIMEOUT and some other > > details > > > > discussed above. > > > > > > > > On Mon, Feb 7, 2022 at 5:42 PM Igor Sapego > wrote: > > > > > > > > > Feature seems useful for me as it makes connection management more > > > robust > > > > > and > > > > > predictable. > > > > > > > > > > I agree with Pavel, that we should print warning when heartbeat > > period > > > is > > > > > larger than > > > > > idle timeout, but I see a problem here as idle timeout is > configured > > on > > > > > server and is not > > > > > known to clients, while heartbeats configured on clients and their > > > period > > > > > is not known > > > > > to the server. Maybe clients should pass this information on to the > > > > > handshake. > > > > > > > > > > Regarding Python and PHP clients - can not we use some kind of > timers > > > to > > > > > implement > > > > > this feature? > > > > > > > > > > Best Regards, > > > > > Igor > > > > > > > > > > > > > > > On Mon, Feb 7, 2022 at 5:23 PM Pavel Tupitsyn < > ptupit...@apache.org> > > > > > wrote: > > > > > > > > > > > Maksim, agree. Let's not be too clever and only log a warning. > > > > > > > > > > > > On Mon, Feb 7, 2022 at 5:23 PM Pavel Tupitsyn < > > ptupit...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > Ivan, idleTimeout already exists, I don't think we should > change > > > the > > > > > way > > > > > > > it works (or did I misunderstand you?) > > > > > > > > > > > > > > Of course, enabling heartbeats means that otherwise idle > clients > > > will > > > > > no > > > > > > > longer be disconnected by the server. > > > > > > > I think we should cross-link those properties in the > > documentation > > > > and > > > > > > > explain this behavior. > > > > > > > > > > > > > > On Mon, Feb 7, 2022 at 4:39 PM Ivan Daschinsky < > > > ivanda...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > >> >>3. Already implemented: when > > > > > ClientConnectorConfiguration#idleTimeout > > > > > > is > > > > > > >> not zero, server disconnects idle clients > > > > > > >> >> > > > > > > >> But I suppose it would be great to have: > > > > > > >> 1. If client supports keep alive, use idleTimeout > > > > > > >> 2. If not, do not use it. > > > > > > >> > > > > > > >> But I am not sure if it is correct or not. > > > > > > >> > > > > > > >> пн, 7 февр. 2022 г. в 16:01, Maksim Timonin < > > > > timoninma...@apache.org > > > > > >: > > > > > > >> > > > > > > >> > I believe explicit is better than implicit :) Also in case > of > > > > > dynamic > > > > > > >> > calculation of timeout, it can change dynamically, for > example > > > > > > >> restarting a > > > > > > >> > cluster with different configuration should reconfigure > > clients > > > > too. > > > > > > >> Looks > > > > > > >> > complicated. > > > > > > >> > > > > > > > >> > My vote for WARN + javadocs with mention of this issue. > > > > > > >> > > > > > > > >> > On Mon, Feb 7, 2022 at 3:51 PM Pavel Tupitsyn < > > > > ptupit...@apache.org > > > > > > > > > > > > >> > wrote: > > > > > > >> >
Re: [ANNOUNCE] Welcome Pavel Pereslegin as a new committer
My congratulations, Pavel! чт, 10 февр. 2022 г. в 18:53, Дмитрий Сорокин : > > Great job Pavel, my congrats! > > > Чт, 10 февр. 2022 г. в 18:29, Nikolay Izhikov : > > > Great news! Congratulations! > > > > > 10 февр. 2022 г., в 18:26, Maksim Timonin > > написал(а): > > > > > > Hi Pavel, > > > > > > Congratulations! > > > > > > On Thu, Feb 10, 2022 at 6:16 PM Maxim Muzafarov > > wrote: > > > > > >> The Project Management Committee (PMC) for Apache Ignite has invited > > >> Pavel Pereslegin to become a committer and we are pleased to announce > > that > > >> he has accepted. > > >> > > >> He made a lot of major contributions to the Apache Ignite codebase > > >> like a snapshot restore procedure, batch update operation to the > > >> PageMemory, TDE cache key rotation procedure, Service context > > >> injection and etc. > > >> > > >> Being a committer enables easier contribution to the project since > > there is > > >> no need to go via the patch submission process. This should enable > > better > > >> productivity. > > >> > > >> Please join me in welcoming Pavel, and congratulating him on the new > > role > > >> in > > >> the Apache Ignite Community. > > >> > > >> > > >> Best Regards, > > >> Maxim Muzafarov > > >> > > > > -- Best wishes, Amelchev Nikita
Re: [ANNOUNCE] Welcome Pavel Pereslegin as a new committer
Great job Pavel, my congrats! Чт, 10 февр. 2022 г. в 18:29, Nikolay Izhikov : > Great news! Congratulations! > > > 10 февр. 2022 г., в 18:26, Maksim Timonin > написал(а): > > > > Hi Pavel, > > > > Congratulations! > > > > On Thu, Feb 10, 2022 at 6:16 PM Maxim Muzafarov > wrote: > > > >> The Project Management Committee (PMC) for Apache Ignite has invited > >> Pavel Pereslegin to become a committer and we are pleased to announce > that > >> he has accepted. > >> > >> He made a lot of major contributions to the Apache Ignite codebase > >> like a snapshot restore procedure, batch update operation to the > >> PageMemory, TDE cache key rotation procedure, Service context > >> injection and etc. > >> > >> Being a committer enables easier contribution to the project since > there is > >> no need to go via the patch submission process. This should enable > better > >> productivity. > >> > >> Please join me in welcoming Pavel, and congratulating him on the new > role > >> in > >> the Apache Ignite Community. > >> > >> > >> Best Regards, > >> Maxim Muzafarov > >> > >
Re: [ANNOUNCE] Welcome Pavel Pereslegin as a new committer
Great news! Congratulations! > 10 февр. 2022 г., в 18:26, Maksim Timonin > написал(а): > > Hi Pavel, > > Congratulations! > > On Thu, Feb 10, 2022 at 6:16 PM Maxim Muzafarov wrote: > >> The Project Management Committee (PMC) for Apache Ignite has invited >> Pavel Pereslegin to become a committer and we are pleased to announce that >> he has accepted. >> >> He made a lot of major contributions to the Apache Ignite codebase >> like a snapshot restore procedure, batch update operation to the >> PageMemory, TDE cache key rotation procedure, Service context >> injection and etc. >> >> Being a committer enables easier contribution to the project since there is >> no need to go via the patch submission process. This should enable better >> productivity. >> >> Please join me in welcoming Pavel, and congratulating him on the new role >> in >> the Apache Ignite Community. >> >> >> Best Regards, >> Maxim Muzafarov >>
Re: [ANNOUNCE] Welcome Pavel Pereslegin as a new committer
Hi Pavel, Congratulations! On Thu, Feb 10, 2022 at 6:16 PM Maxim Muzafarov wrote: > The Project Management Committee (PMC) for Apache Ignite has invited > Pavel Pereslegin to become a committer and we are pleased to announce that > he has accepted. > > He made a lot of major contributions to the Apache Ignite codebase > like a snapshot restore procedure, batch update operation to the > PageMemory, TDE cache key rotation procedure, Service context > injection and etc. > > Being a committer enables easier contribution to the project since there is > no need to go via the patch submission process. This should enable better > productivity. > > Please join me in welcoming Pavel, and congratulating him on the new role > in > the Apache Ignite Community. > > > Best Regards, > Maxim Muzafarov >
Re: [ANNOUNCE] Welcome Pavel Pereslegin as a new committer
Congrats, Pasha! чт, 10 февр. 2022 г. в 18:16, Maxim Muzafarov : > The Project Management Committee (PMC) for Apache Ignite has invited > Pavel Pereslegin to become a committer and we are pleased to announce that > he has accepted. > > He made a lot of major contributions to the Apache Ignite codebase > like a snapshot restore procedure, batch update operation to the > PageMemory, TDE cache key rotation procedure, Service context > injection and etc. > > Being a committer enables easier contribution to the project since there is > no need to go via the patch submission process. This should enable better > productivity. > > Please join me in welcoming Pavel, and congratulating him on the new role > in > the Apache Ignite Community. > > > Best Regards, > Maxim Muzafarov > -- Sincerely yours, Ivan Daschinskiy
[ANNOUNCE] Welcome Pavel Pereslegin as a new committer
The Project Management Committee (PMC) for Apache Ignite has invited Pavel Pereslegin to become a committer and we are pleased to announce that he has accepted. He made a lot of major contributions to the Apache Ignite codebase like a snapshot restore procedure, batch update operation to the PageMemory, TDE cache key rotation procedure, Service context injection and etc. Being a committer enables easier contribution to the project since there is no need to go via the patch submission process. This should enable better productivity. Please join me in welcoming Pavel, and congratulating him on the new role in the Apache Ignite Community. Best Regards, Maxim Muzafarov
Re: Re[2]: Apache Ignite 2.13 RELEASE [Time, Scope, Manager]
Guys, +1 to await merge of the Calcite SQL engine before code-freeze phase and release branch cutting. Other features and fixes can be awaited too, it's discussable. But the 2.12 branch was cut on October 15, 2021. There are many fixes and features that were merged into the master during this period. The total time between branches cut is 5 months (if there is no delay happens). Seems it is not so frequently. чт, 10 февр. 2022 г. в 15:17, Zhenya Stanilovsky : > > > Maxim, i think that more frequent releases are useful. > Ready to release branch means that it passed all known tests and also have an > appropriate votes. > More code changes creates more difficulties in final tests and sometimes > migration. > No need to switch between neighbor minor versions for user if all work > properly well. > I «vote» for more frequent releases. > > > > >> > >>>Hi, guys! > >>> > >>>Ignite 2.12 was released on 17th Jan. And here is a plan to release 2.13 on > >>>28 Mar. It is only 2.5 months between those versions. IMHO, it's better to > >>>have more time between releases: > >>>1. We had some bug reports after releasing 2.11, and it can be worth > >>>waiting for users feedback about 2.12. Also meetup with description of 2.12 > >>>will be only next week (16 Feb). > >>>2. In my understanding, users don't switch between versions of databases > >>>frequently. Actually it's hard work to upgrade such a dependency. So, no > >>>need for continuous delivery here. I think it's a common practice, for > >>>example, MongoDB releases 1 time per year, Cassandra 2 times. CockroachDB > >>>releases minor versions every month, but major versions are still released > >>>2 times a year. But I'm not aware of all databases. > >>> > >>>I think we should move dates for at least 1 month. Also it depends on the > >>>Calcite engine readiness. WDYT? > >>> > >>>Anyway, from my side there are some tickets I want to include to the next > >>>release scope: > >>>1. Partition reservation for cache queries (it will make IndexQuery work on > >>>unstable topology): IGNITE-16030 and IGNITE-16031 > >>> > >>>2. Also there is a discussion started by Andrey Mashenlov about known index > >>>corruption scenarios [1]. It looks like there are at least 2 issues to > >>>resolve: dropping of affinity index, handle of orphaned indexes. I think we > >>>should fix those known issues before the next release. WDYT? > >>> > >>>[1] https://lists.apache.org/thread/m6dt0pn1qb01d8w6zm2fvo7lxgt0r068 > >>> > >>> > >>>On Wed, Feb 9, 2022 at 3:13 PM Maxim Muzafarov < mmu...@apache.org > wrote: > >>> > Nikita, > > Thank you for starting this thread. > +1 for these dates, but I think it's better to start the code freeze > date when the Calcite engine will be actually merged to the master > branch. > > On Tue, 8 Feb 2022 at 13:10, Nikita Amelchev < namelc...@apache.org > > wrote: > > > > Dear Ignite Community! > > > > I suggest starting Apache Ignite 2.13 release activities. > > > > There is a plan to merge the new Calcite SQL engine. [1] I think that > > 2.13 is a good candidate for it. > > > > Moreover, we've accumulated a hundred resolved [2] issues with new > > features and bug fixes which are waiting for their release date. For > > example, > > > > BinaryArray introduced, > > Read Repair strategies implemented, > > CPP Thin: asynchronous network events handling, > > NUMA-aware allocator for data regions > > etc. > > > > I want to propose myself to be the release manager of the planning > release. > > > > I propose the following timeline: > > > > Scope Freeze: February 21, 2022 > > Code Freeze: March 7, 2022 > > Voting Date: March 21, 2022 > > Release Date: March 28, 2022 > > > > WDYT? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15436 > > [2] > > https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.13%27))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20ORDER%20BY%20priority > > > > -- > > Best wishes, > > Amelchev Nikita > > >> > >> > >> > >> -- Best wishes, Amelchev Nikita
Re: Re[2]: Apache Ignite 2.13 RELEASE [Time, Scope, Manager]
> I «vote» for more frequent releases. +1 Hotfixes, eg. 2.12.1, should be released asap (no need to wait for 2.13). And it's ok to release 2.13 without fixes planned for 2.12.1 since not all users are affected but some wait for features like "Consistency check & repair". On Thu, Feb 10, 2022 at 3:17 PM Zhenya Stanilovsky wrote: > > Maxim, i think that more frequent releases are useful. > Ready to release branch means that it passed all known tests and also have > an appropriate votes. > More code changes creates more difficulties in final tests and sometimes > migration. > No need to switch between neighbor minor versions for user if all work > properly well. > I «vote» for more frequent releases. > > > > >> > >>>Hi, guys! > >>> > >>>Ignite 2.12 was released on 17th Jan. And here is a plan to release > 2.13 on > >>>28 Mar. It is only 2.5 months between those versions. IMHO, it's better > to > >>>have more time between releases: > >>>1. We had some bug reports after releasing 2.11, and it can be worth > >>>waiting for users feedback about 2.12. Also meetup with description of > 2.12 > >>>will be only next week (16 Feb). > >>>2. In my understanding, users don't switch between versions of databases > >>>frequently. Actually it's hard work to upgrade such a dependency. So, no > >>>need for continuous delivery here. I think it's a common practice, for > >>>example, MongoDB releases 1 time per year, Cassandra 2 times. > CockroachDB > >>>releases minor versions every month, but major versions are still > released > >>>2 times a year. But I'm not aware of all databases. > >>> > >>>I think we should move dates for at least 1 month. Also it depends on > the > >>>Calcite engine readiness. WDYT? > >>> > >>>Anyway, from my side there are some tickets I want to include to the > next > >>>release scope: > >>>1. Partition reservation for cache queries (it will make IndexQuery > work on > >>>unstable topology): IGNITE-16030 and IGNITE-16031 > >>> > >>>2. Also there is a discussion started by Andrey Mashenlov about known > index > >>>corruption scenarios [1]. It looks like there are at least 2 issues to > >>>resolve: dropping of affinity index, handle of orphaned indexes. I > think we > >>>should fix those known issues before the next release. WDYT? > >>> > >>>[1] https://lists.apache.org/thread/m6dt0pn1qb01d8w6zm2fvo7lxgt0r068 > >>> > >>> > >>>On Wed, Feb 9, 2022 at 3:13 PM Maxim Muzafarov < mmu...@apache.org > > wrote: > >>> > Nikita, > > Thank you for starting this thread. > +1 for these dates, but I think it's better to start the code freeze > date when the Calcite engine will be actually merged to the master > branch. > > On Tue, 8 Feb 2022 at 13:10, Nikita Amelchev < namelc...@apache.org > > wrote: > > > > Dear Ignite Community! > > > > I suggest starting Apache Ignite 2.13 release activities. > > > > There is a plan to merge the new Calcite SQL engine. [1] I think > that > > 2.13 is a good candidate for it. > > > > Moreover, we've accumulated a hundred resolved [2] issues with new > > features and bug fixes which are waiting for their release date. For > > example, > > > > BinaryArray introduced, > > Read Repair strategies implemented, > > CPP Thin: asynchronous network events handling, > > NUMA-aware allocator for data regions > > etc. > > > > I want to propose myself to be the release manager of the planning > release. > > > > I propose the following timeline: > > > > Scope Freeze: February 21, 2022 > > Code Freeze: March 7, 2022 > > Voting Date: March 21, 2022 > > Release Date: March 28, 2022 > > > > WDYT? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15436 > > [2] > > https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.13%27))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20ORDER%20BY%20priority > > > > -- > > Best wishes, > > Amelchev Nikita > > >> > >> > >> > >>
Re[2]: Apache Ignite 2.13 RELEASE [Time, Scope, Manager]
Maxim, i think that more frequent releases are useful. Ready to release branch means that it passed all known tests and also have an appropriate votes. More code changes creates more difficulties in final tests and sometimes migration. No need to switch between neighbor minor versions for user if all work properly well. I «vote» for more frequent releases. > >> >>>Hi, guys! >>> >>>Ignite 2.12 was released on 17th Jan. And here is a plan to release 2.13 on >>>28 Mar. It is only 2.5 months between those versions. IMHO, it's better to >>>have more time between releases: >>>1. We had some bug reports after releasing 2.11, and it can be worth >>>waiting for users feedback about 2.12. Also meetup with description of 2.12 >>>will be only next week (16 Feb). >>>2. In my understanding, users don't switch between versions of databases >>>frequently. Actually it's hard work to upgrade such a dependency. So, no >>>need for continuous delivery here. I think it's a common practice, for >>>example, MongoDB releases 1 time per year, Cassandra 2 times. CockroachDB >>>releases minor versions every month, but major versions are still released >>>2 times a year. But I'm not aware of all databases. >>> >>>I think we should move dates for at least 1 month. Also it depends on the >>>Calcite engine readiness. WDYT? >>> >>>Anyway, from my side there are some tickets I want to include to the next >>>release scope: >>>1. Partition reservation for cache queries (it will make IndexQuery work on >>>unstable topology): IGNITE-16030 and IGNITE-16031 >>> >>>2. Also there is a discussion started by Andrey Mashenlov about known index >>>corruption scenarios [1]. It looks like there are at least 2 issues to >>>resolve: dropping of affinity index, handle of orphaned indexes. I think we >>>should fix those known issues before the next release. WDYT? >>> >>>[1] https://lists.apache.org/thread/m6dt0pn1qb01d8w6zm2fvo7lxgt0r068 >>> >>> >>>On Wed, Feb 9, 2022 at 3:13 PM Maxim Muzafarov < mmu...@apache.org > wrote: >>> Nikita, Thank you for starting this thread. +1 for these dates, but I think it's better to start the code freeze date when the Calcite engine will be actually merged to the master branch. On Tue, 8 Feb 2022 at 13:10, Nikita Amelchev < namelc...@apache.org > wrote: > > Dear Ignite Community! > > I suggest starting Apache Ignite 2.13 release activities. > > There is a plan to merge the new Calcite SQL engine. [1] I think that > 2.13 is a good candidate for it. > > Moreover, we've accumulated a hundred resolved [2] issues with new > features and bug fixes which are waiting for their release date. For > example, > > BinaryArray introduced, > Read Repair strategies implemented, > CPP Thin: asynchronous network events handling, > NUMA-aware allocator for data regions > etc. > > I want to propose myself to be the release manager of the planning release. > > I propose the following timeline: > > Scope Freeze: February 21, 2022 > Code Freeze: March 7, 2022 > Voting Date: March 21, 2022 > Release Date: March 28, 2022 > > WDYT? > > [1] https://issues.apache.org/jira/browse/IGNITE-15436 > [2] https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.13%27))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20ORDER%20BY%20priority > > -- > Best wishes, > Amelchev Nikita >> >> >> >>
Re: Apache Ignite 2.13 RELEASE [Time, Scope, Manager]
Hi, guys! Ignite 2.12 was released on 17th Jan. And here is a plan to release 2.13 on 28 Mar. It is only 2.5 months between those versions. IMHO, it's better to have more time between releases: 1. We had some bug reports after releasing 2.11, and it can be worth waiting for users feedback about 2.12. Also meetup with description of 2.12 will be only next week (16 Feb). 2. In my understanding, users don't switch between versions of databases frequently. Actually it's hard work to upgrade such a dependency. So, no need for continuous delivery here. I think it's a common practice, for example, MongoDB releases 1 time per year, Cassandra 2 times. CockroachDB releases minor versions every month, but major versions are still released 2 times a year. But I'm not aware of all databases. I think we should move dates for at least 1 month. Also it depends on the Calcite engine readiness. WDYT? Anyway, from my side there are some tickets I want to include to the next release scope: 1. Partition reservation for cache queries (it will make IndexQuery work on unstable topology): IGNITE-16030 and IGNITE-16031 2. Also there is a discussion started by Andrey Mashenlov about known index corruption scenarios [1]. It looks like there are at least 2 issues to resolve: dropping of affinity index, handle of orphaned indexes. I think we should fix those known issues before the next release. WDYT? [1] https://lists.apache.org/thread/m6dt0pn1qb01d8w6zm2fvo7lxgt0r068 On Wed, Feb 9, 2022 at 3:13 PM Maxim Muzafarov wrote: > Nikita, > > Thank you for starting this thread. > +1 for these dates, but I think it's better to start the code freeze > date when the Calcite engine will be actually merged to the master > branch. > > On Tue, 8 Feb 2022 at 13:10, Nikita Amelchev wrote: > > > > Dear Ignite Community! > > > > I suggest starting Apache Ignite 2.13 release activities. > > > > There is a plan to merge the new Calcite SQL engine. [1] I think that > > 2.13 is a good candidate for it. > > > > Moreover, we've accumulated a hundred resolved [2] issues with new > > features and bug fixes which are waiting for their release date. For > > example, > > > > BinaryArray introduced, > > Read Repair strategies implemented, > > CPP Thin: asynchronous network events handling, > > NUMA-aware allocator for data regions > > etc. > > > > I want to propose myself to be the release manager of the planning > release. > > > > I propose the following timeline: > > > > Scope Freeze: February 21, 2022 > > Code Freeze: March 7, 2022 > > Voting Date: March 21, 2022 > > Release Date: March 28, 2022 > > > > WDYT? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15436 > > [2] > https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.13%27))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20ORDER%20BY%20priority > > > > -- > > Best wishes, > > Amelchev Nikita >
