Re: Why WAL archives enabled by default?
Hi, Ivan! I have only described ideas. But here are a few more details. We can take care not to go beyond DataStorageConfiguration#maxWalArchiveSize. Before increasing the size of WAL archive (transferring to archive /rollOver, compression, decompression), we can make sure that there will be enough space in the archive and if there is no such, then we will try to clean it. We cannot delete those segments that are required for recovery (between the last two checkpoints) and reserved for example for historical rebalancing. We can receive a notification about the change of checkpoints and the reservation / release of segments, thus we can know how many segments we can delete right now. 06.11.2020, 09:53, "Ivan Daschinsky" : >>> For example, when trying to move a segment to the archive. > > We cannot do this, we will lost data. We can truncate archived segment if > and only if it is not required for recovery. If last checkpoint marker > points to segment > with lower index, we cannot delete any segment with higher index. So the > only moment where we can remove truncate segments is a finish of checkpoint. > > пт, 6 нояб. 2020 г. в 09:46, ткаленко кирилл : > >> Hello, everybody! >> >> As far as I know, WAL archive is used for PITP(GridGain feature) and >> historical rebalancing. >> >> Facundo seems to have a problem with running out of directory >> (/opt/work/walarchive) space. >> Currently, WAL archive is cleared at the end of checkpoint. Potentially >> long transaction may prevent checkpoint starting, thereby not cleaning WAL >> archive, which will lead to such an error. >> At the moment, I see such a WA to increase size of directory >> (/opt/work/walarchive) in k8s and avoid long transactions or something like >> that that modifies data and runs for a long time. >> >> And it is best to fix the logic of working with WAL archive. I think we >> should remove WAL archive cleanup from the end of the checkpoint and do it >> on demand. For example, when trying to move a segment to the archive. >> >> 06.11.2020, 01:58, "Denis Magda" : >> > Folks, >> > >> > In my understanding, you need the archives only for features such as >> PITR. >> > Considering, that the PITR functionality is not provided in Ignite why do >> > we have the archives enabled by default? >> > >> > How about having this feature disabled by default to prevent the >> following >> > issues experienced by our users: >> > >> >> http://apache-ignite-users.70518.x6.nabble.com/WAL-and-WAL-Archive-volume-size-recommendation-td34458.html >> > >> > - >> > Denis > > -- > Sincerely yours, Ivan Daschinskiy
Re: Why WAL archives enabled by default?
>> For example, when trying to move a segment to the archive. We cannot do this, we will lost data. We can truncate archived segment if and only if it is not required for recovery. If last checkpoint marker points to segment with lower index, we cannot delete any segment with higher index. So the only moment where we can remove truncate segments is a finish of checkpoint. пт, 6 нояб. 2020 г. в 09:46, ткаленко кирилл : > Hello, everybody! > > As far as I know, WAL archive is used for PITP(GridGain feature) and > historical rebalancing. > > Facundo seems to have a problem with running out of directory > (/opt/work/walarchive) space. > Currently, WAL archive is cleared at the end of checkpoint. Potentially > long transaction may prevent checkpoint starting, thereby not cleaning WAL > archive, which will lead to such an error. > At the moment, I see such a WA to increase size of directory > (/opt/work/walarchive) in k8s and avoid long transactions or something like > that that modifies data and runs for a long time. > > And it is best to fix the logic of working with WAL archive. I think we > should remove WAL archive cleanup from the end of the checkpoint and do it > on demand. For example, when trying to move a segment to the archive. > > > 06.11.2020, 01:58, "Denis Magda" : > > Folks, > > > > In my understanding, you need the archives only for features such as > PITR. > > Considering, that the PITR functionality is not provided in Ignite why do > > we have the archives enabled by default? > > > > How about having this feature disabled by default to prevent the > following > > issues experienced by our users: > > > http://apache-ignite-users.70518.x6.nabble.com/WAL-and-WAL-Archive-volume-size-recommendation-td34458.html > > > > - > > Denis > -- Sincerely yours, Ivan Daschinskiy
Re: Why WAL archives enabled by default?
Hello, everybody! As far as I know, WAL archive is used for PITP(GridGain feature) and historical rebalancing. Facundo seems to have a problem with running out of directory (/opt/work/walarchive) space. Currently, WAL archive is cleared at the end of checkpoint. Potentially long transaction may prevent checkpoint starting, thereby not cleaning WAL archive, which will lead to such an error. At the moment, I see such a WA to increase size of directory (/opt/work/walarchive) in k8s and avoid long transactions or something like that that modifies data and runs for a long time. And it is best to fix the logic of working with WAL archive. I think we should remove WAL archive cleanup from the end of the checkpoint and do it on demand. For example, when trying to move a segment to the archive. 06.11.2020, 01:58, "Denis Magda" : > Folks, > > In my understanding, you need the archives only for features such as PITR. > Considering, that the PITR functionality is not provided in Ignite why do > we have the archives enabled by default? > > How about having this feature disabled by default to prevent the following > issues experienced by our users: > http://apache-ignite-users.70518.x6.nabble.com/WAL-and-WAL-Archive-volume-size-recommendation-td34458.html > > - > Denis
Re: Ignite 2.9 Announcement Blog Post
Igniters, Ignite 2.9 announce blog post is published now: [1] [1] : https://blogs.apache.org/ignite/entry/apache-ignite-2-9-released пт, 25 сент. 2020 г. в 11:04, Alex Plehanov : > Denis, > > Ok, I will prepare the text soon. > > чт, 24 сент. 2020 г. в 23:36, Denis Magda : > >> @Alex Plehanov >> >> Are you interested in writing a blog post that covers the major >> improvements of the 2.9 release? It will be referenced from the >> announcement email and distributed through other channels. Examples of >> previous articles: https://blogs.apache.org/ignite/ >> >> It happened that I was the only one who would write such an article but >> will step down with pleasure if you can take over this task. Once the >> draft >> is ready, I'll ask a professional technical editor, who reviews my texts, >> to work with you as well. >> >> - >> Denis >> >
[jira] [Created] (IGNITE-13680) Broken formatting rule for vm.swappiness.
Stanilovsky Evgeny created IGNITE-13680:
---
Summary: Broken formatting rule for vm.swappiness.
Key: IGNITE-13680
URL: https://issues.apache.org/jira/browse/IGNITE-13680
Project: Ignite
Issue Type: Improvement
Components: general
Affects Versions: 2.9
Reporter: Stanilovsky Evgeny
Ignite start suggestions use float formatting for int value :
{noformat}
^-- Reduce pages swapping ratio (set vm.swappiness=10.00 or less)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13679) Entryprocessor cannot be hot deployed properly via UriDeploymentSpi
YuJue Li created IGNITE-13679: - Summary: Entryprocessor cannot be hot deployed properly via UriDeploymentSpi Key: IGNITE-13679 URL: https://issues.apache.org/jira/browse/IGNITE-13679 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.9 Reporter: YuJue Li Fix For: 2.9.1 Attachments: ignite-deploy.zip Entryprocessor cannot be hot deployed properly via UriDeploymentSpi,the operation steps are as follows: 1.put jar in the specified folder of uriList; 2.Use example-deploy.xml,start two ignite nodes; 3.Use the DeployClient to deploy the service named "deployService"; 4.Execute the test through ThickClientTest, and the result is correct; 5.Modify the code of DeployServiceImpl and DeployEntryProcessor, for example, change "Hello" to "Hi", then repackage it and put it into the specified folder of uriList; 6.Redeploy services by RedeployClient; 7.Execute the test again through ThickClientTest, and the result is incorrect,we will find that if the Entryprocessor accessed by the service is on another node, the Entryprocessor uses the old version of the class definition. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Why WAL archives enabled by default?
Folks, In my understanding, you need the archives only for features such as PITR. Considering, that the PITR functionality is not provided in Ignite why do we have the archives enabled by default? How about having this feature disabled by default to prevent the following issues experienced by our users: http://apache-ignite-users.70518.x6.nabble.com/WAL-and-WAL-Archive-volume-size-recommendation-td34458.html - Denis
Re: 2.9.1 release scope and dates
Ivan, hi! Sure. UPD: i am the release manager and will be doing this with Maxim's help (since i don't have some user permissions) On Thu, Nov 5, 2020 at 6:24 PM Ivan Daschinsky wrote: > Hi. I'd suggest to add this issue. This is a usability improvement for zk > discovery, and also this patch incorporates fixes for JMX metrics > concurrency issues > > [1] -- https://issues.apache.org/jira/browse/IGNITE-13577 > > чт, 5 нояб. 2020 г., 16:20 Yaroslav Molochkov : > > > Igniters! > > > > I'd like to help with the 2.9.1 release. The scope of this release > includes > > following issues: > > > > > https://issues.apache.org/jira/browse/IGNITE-13676?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 > > > > Maxim Muzafarov agreed to help me with the process and he will be the > > release manager. > > > > Scope freeze: Nov. 12th > > Code freeze: Nov. 19th > > Voting date: Nov. 26th > > Release date: Nov. 31st > > > > Tickets that were added (or to be added) to the scope don't bring new > > features but various bug fixes. > > >
[jira] [Created] (IGNITE-13678) Extend test coverage for persistence files dir and WAL page snapshot records compression
Sergey Uttsel created IGNITE-13678: -- Summary: Extend test coverage for persistence files dir and WAL page snapshot records compression Key: IGNITE-13678 URL: https://issues.apache.org/jira/browse/IGNITE-13678 Project: Ignite Issue Type: Test Reporter: Sergey Uttsel Assignee: Sergey Uttsel -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: 2.9.1 release scope and dates
Hi. I'd suggest to add this issue. This is a usability improvement for zk discovery, and also this patch incorporates fixes for JMX metrics concurrency issues [1] -- https://issues.apache.org/jira/browse/IGNITE-13577 чт, 5 нояб. 2020 г., 16:20 Yaroslav Molochkov : > Igniters! > > I'd like to help with the 2.9.1 release. The scope of this release includes > following issues: > > https://issues.apache.org/jira/browse/IGNITE-13676?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 > > Maxim Muzafarov agreed to help me with the process and he will be the > release manager. > > Scope freeze: Nov. 12th > Code freeze: Nov. 19th > Voting date: Nov. 26th > Release date: Nov. 31st > > Tickets that were added (or to be added) to the scope don't bring new > features but various bug fixes. >
[jira] [Created] (IGNITE-13677) Calcite integration. TableSpool
Taras Ledkov created IGNITE-13677:
-
Summary: Calcite integration. TableSpool
Key: IGNITE-13677
URL: https://issues.apache.org/jira/browse/IGNITE-13677
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov
The first step of the IGNITE-13545: adds TableSpool.
We have to add new trait: {{CorretlationTrait}} to check stream correlation.
Without check this trait Filter with correlated variables may be places under
Exchange.
So, {{IgniteCorrelatedNestedLoopJoin}} requires correlated stream from the
right input and {{Exchange}} may produce only uncorrelated stream.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
2.9.1 release scope and dates
Igniters! I'd like to help with the 2.9.1 release. The scope of this release includes following issues: https://issues.apache.org/jira/browse/IGNITE-13676?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 Maxim Muzafarov agreed to help me with the process and he will be the release manager. Scope freeze: Nov. 12th Code freeze: Nov. 19th Voting date: Nov. 26th Release date: Nov. 31st Tickets that were added (or to be added) to the scope don't bring new features but various bug fixes.
[jira] [Created] (IGNITE-13676) Java thin client: Message not fully read by client after SECURITY_VIOLATION error
Aleksey Plekhanov created IGNITE-13676: -- Summary: Java thin client: Message not fully read by client after SECURITY_VIOLATION error Key: IGNITE-13676 URL: https://issues.apache.org/jira/browse/IGNITE-13676 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov In case of SECURITY_VIOLATION error client does not fully read message, these leads to phantom messages and connection drop. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: 2.9.1 release proposal
Folks, Alexey, Sure, I forgot about the Christmas holidays. I don't think we will be able to complete our release procedures with-in the next few weeks, so let's shift the dates a bit late. Let's prepare everything prior to the holidays and set the TC.Bot for the stabilization period on holidays to catch all the flaky issues. Code Freeze: December 25th, 2020 Release Date: January 18th, 2021 WDYT? On Thu, 5 Nov 2020 at 13:42, Alexey Goncharuk wrote: > > Maxim, > > Should we shift the dates so they are not too close to state holidays in > various countries? I'm concerned we won't be getting much activity around > holidays and people who would otherwise spend some time on testing the > release will not be able to do so. > > чт, 5 нояб. 2020 г. в 12:21, Maxim Muzafarov : > > > Folks, > > > > What may be the comfortable dates of the 2.10 release to finish all > > the related development activities? > > I suggest release Apache Ignite 2.10 prior to the end of this year and > > focus on the 3.0 activities in 2021 with only bug-fix releases for the > > 2.10.x. > > > > I suggest the following release dates for the 2.10: > > > > Code Freeze: December 16th, 2020 > > Release Date: December 30th, 2020 > > > > On Tue, 3 Nov 2020 at 18:15, Yaroslav Molochkov > > wrote: > > > > > > Nikolay, hi! > > > > > > Done. > > > > > > On Tue, Nov 3, 2020 at 10:48 AM Nikolay Izhikov > > wrote: > > > > > > > Hello, Yaroslav. > > > > > > > > Looks like we have fixVersion 2.9.1 in Jira. > > > > Let’s mark all tickets with label «2.9.1-rc1» with fixVersion=2.9.1 and > > > > use fixVersion instead of label further. > > > > > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 > > > > > > > > > 2 нояб. 2020 г., в 19:42, Yaroslav Molochkov > > > > написал(а): > > > > > > > > > > Guys, > > > > > > > > > > should you agree that issues with the 2.9.1-rc tag are good enough > > > > > for a maintenance release, i'd like to give it a go. > > > > > > > > > > On Thu, Oct 29, 2020 at 5:33 PM Alexey Zinoviev < > > zaleslaw@gmail.com> > > > > > wrote: > > > > > > > > > >> Let's discuss the possible planning dates for feature freeze for > > 2.10, > > > > for > > > > >> example? Do you have any plans or ideas? > > > > >> > > > > >> чт, 29 окт. 2020 г. в 17:24, Andrey Gura : > > > > >> > > > > >>> Hi, > > > > >>> > > > > >>> I agree with Alexey. We should release 2.9.1 and start preparing > > for > > > > >>> the 2.10 release. > > > > >>> > > > > >>> 2.x releases usually take a lot of time. So we can release 2.9.1, > > and > > > > >>> even 2.9.2 before 2.10. > > > > >>> > > > > >>> On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk > > > > >>> wrote: > > > > > > > > Hello folks, > > > > > > > > I think we should start both 2.9.1 and 2.10. In practice, > > maintenance > > > > release contains only critical and usability bugfixes (for > > example, I > > > > >>> would > > > > include this ticket [1] to include in 2.9.1 as it prevents users > > from > > > > >>> using > > > > tracing) and is released much faster than a minor release. > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13640 > > > > > > > > вт, 27 окт. 2020 г. в 21:41, Guru Stron < > > gurustronpub...@gmail.com>: > > > > > > > > > Hello, > > > > > > > > > > Agree with Pavel. > > > > > > > > > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn < > > ptupit...@apache.org> > > > > >>> wrote: > > > > > > > > > >> Igniters, > > > > >> > > > > >> I think we should plan 2.10 instead of 2.9.1. > > > > >> ignite-2.9 branch was cut 4 months ago, a bunch of new features > > are > > > > > waiting > > > > >> to be released. > > > > >> > > > > >> On Tue, Oct 27, 2020 at 4:23 AM 18624049226 < > > 18624049...@163.com> > > > > >>> wrote: > > > > >> > > > > >>> Hello, > > > > >>> > > > > >>> I suggest that the remaining document issue in version 2.9.0 > > can > > > > >> be > > > > >>> solved in version 2.9.1, and it is not a good practice to > > > > >> postpone > > > > >>> to > > > > >>> version 2.10. > > > > >>> > > > > >>> 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > > > Hello, > > > > > > > > +1 > > > > Should we start the discussion about the release leader and > > > > >>> release > > > > >>> dates? > > > > > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > > > > > > > wrote: > > > > > +1 to start the 2.9.1 release process once as soon as 2.9 > > > > >>> released. > > > > > > > > > > On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > > > > > nizhi...@apache.org> > > > > >>> wrote: > > > > > > > > > >> Hello, Yaroslav. > > > > >> > > > > >> I support the idea. > > > > >> But, we should carefully work with the release scope. > > > >
Re: 2.9.1 release proposal
Maxim, Should we shift the dates so they are not too close to state holidays in various countries? I'm concerned we won't be getting much activity around holidays and people who would otherwise spend some time on testing the release will not be able to do so. чт, 5 нояб. 2020 г. в 12:21, Maxim Muzafarov : > Folks, > > What may be the comfortable dates of the 2.10 release to finish all > the related development activities? > I suggest release Apache Ignite 2.10 prior to the end of this year and > focus on the 3.0 activities in 2021 with only bug-fix releases for the > 2.10.x. > > I suggest the following release dates for the 2.10: > > Code Freeze: December 16th, 2020 > Release Date: December 30th, 2020 > > On Tue, 3 Nov 2020 at 18:15, Yaroslav Molochkov > wrote: > > > > Nikolay, hi! > > > > Done. > > > > On Tue, Nov 3, 2020 at 10:48 AM Nikolay Izhikov > wrote: > > > > > Hello, Yaroslav. > > > > > > Looks like we have fixVersion 2.9.1 in Jira. > > > Let’s mark all tickets with label «2.9.1-rc1» with fixVersion=2.9.1 and > > > use fixVersion instead of label further. > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 > > > > > > > 2 нояб. 2020 г., в 19:42, Yaroslav Molochkov > > > написал(а): > > > > > > > > Guys, > > > > > > > > should you agree that issues with the 2.9.1-rc tag are good enough > > > > for a maintenance release, i'd like to give it a go. > > > > > > > > On Thu, Oct 29, 2020 at 5:33 PM Alexey Zinoviev < > zaleslaw@gmail.com> > > > > wrote: > > > > > > > >> Let's discuss the possible planning dates for feature freeze for > 2.10, > > > for > > > >> example? Do you have any plans or ideas? > > > >> > > > >> чт, 29 окт. 2020 г. в 17:24, Andrey Gura : > > > >> > > > >>> Hi, > > > >>> > > > >>> I agree with Alexey. We should release 2.9.1 and start preparing > for > > > >>> the 2.10 release. > > > >>> > > > >>> 2.x releases usually take a lot of time. So we can release 2.9.1, > and > > > >>> even 2.9.2 before 2.10. > > > >>> > > > >>> On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk > > > >>> wrote: > > > > > > Hello folks, > > > > > > I think we should start both 2.9.1 and 2.10. In practice, > maintenance > > > release contains only critical and usability bugfixes (for > example, I > > > >>> would > > > include this ticket [1] to include in 2.9.1 as it prevents users > from > > > >>> using > > > tracing) and is released much faster than a minor release. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13640 > > > > > > вт, 27 окт. 2020 г. в 21:41, Guru Stron < > gurustronpub...@gmail.com>: > > > > > > > Hello, > > > > > > > > Agree with Pavel. > > > > > > > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn < > ptupit...@apache.org> > > > >>> wrote: > > > > > > > >> Igniters, > > > >> > > > >> I think we should plan 2.10 instead of 2.9.1. > > > >> ignite-2.9 branch was cut 4 months ago, a bunch of new features > are > > > > waiting > > > >> to be released. > > > >> > > > >> On Tue, Oct 27, 2020 at 4:23 AM 18624049226 < > 18624049...@163.com> > > > >>> wrote: > > > >> > > > >>> Hello, > > > >>> > > > >>> I suggest that the remaining document issue in version 2.9.0 > can > > > >> be > > > >>> solved in version 2.9.1, and it is not a good practice to > > > >> postpone > > > >>> to > > > >>> version 2.10. > > > >>> > > > >>> 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > > Hello, > > > > > > +1 > > > Should we start the discussion about the release leader and > > > >>> release > > > >>> dates? > > > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > > > > > wrote: > > > > +1 to start the 2.9.1 release process once as soon as 2.9 > > > >>> released. > > > > > > > > On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > > > > nizhi...@apache.org> > > > >>> wrote: > > > > > > > >> Hello, Yaroslav. > > > >> > > > >> I support the idea. > > > >> But, we should carefully work with the release scope. > > > >> > > > >> IGNITE-13477 - fix for a SQL tracing that will be available > > > >>> only in > > > >>> 2.10 > > > >> IGNITE-13427 - fix for a new system view that exists in > > > >> master > > > > only, > > > >> we > > > >> need to include IGNITE-13409 > > > >> > > > >> Other tickets should be checked, also. > > > >> Is this a real fix of a released bug or we fix some issue we > > > >>> bring > > > >> with > > > >> the brand new contribution. > > > >> > > > >> > > > >> I propose to include the following tickets, also: > > > >> > > > >> CMD tools improvements: > > > >> > > > >> IGNITE-13488 - Command to print
Re: 2.9.1 release proposal
I'm ok with code freeze dates чт, 5 нояб. 2020 г. в 12:21, Maxim Muzafarov : > Folks, > > What may be the comfortable dates of the 2.10 release to finish all > the related development activities? > I suggest release Apache Ignite 2.10 prior to the end of this year and > focus on the 3.0 activities in 2021 with only bug-fix releases for the > 2.10.x. > > I suggest the following release dates for the 2.10: > > Code Freeze: December 16th, 2020 > Release Date: December 30th, 2020 > > On Tue, 3 Nov 2020 at 18:15, Yaroslav Molochkov > wrote: > > > > Nikolay, hi! > > > > Done. > > > > On Tue, Nov 3, 2020 at 10:48 AM Nikolay Izhikov > wrote: > > > > > Hello, Yaroslav. > > > > > > Looks like we have fixVersion 2.9.1 in Jira. > > > Let’s mark all tickets with label «2.9.1-rc1» with fixVersion=2.9.1 and > > > use fixVersion instead of label further. > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 > > > > > > > 2 нояб. 2020 г., в 19:42, Yaroslav Molochkov > > > написал(а): > > > > > > > > Guys, > > > > > > > > should you agree that issues with the 2.9.1-rc tag are good enough > > > > for a maintenance release, i'd like to give it a go. > > > > > > > > On Thu, Oct 29, 2020 at 5:33 PM Alexey Zinoviev < > zaleslaw@gmail.com> > > > > wrote: > > > > > > > >> Let's discuss the possible planning dates for feature freeze for > 2.10, > > > for > > > >> example? Do you have any plans or ideas? > > > >> > > > >> чт, 29 окт. 2020 г. в 17:24, Andrey Gura : > > > >> > > > >>> Hi, > > > >>> > > > >>> I agree with Alexey. We should release 2.9.1 and start preparing > for > > > >>> the 2.10 release. > > > >>> > > > >>> 2.x releases usually take a lot of time. So we can release 2.9.1, > and > > > >>> even 2.9.2 before 2.10. > > > >>> > > > >>> On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk > > > >>> wrote: > > > > > > Hello folks, > > > > > > I think we should start both 2.9.1 and 2.10. In practice, > maintenance > > > release contains only critical and usability bugfixes (for > example, I > > > >>> would > > > include this ticket [1] to include in 2.9.1 as it prevents users > from > > > >>> using > > > tracing) and is released much faster than a minor release. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13640 > > > > > > вт, 27 окт. 2020 г. в 21:41, Guru Stron < > gurustronpub...@gmail.com>: > > > > > > > Hello, > > > > > > > > Agree with Pavel. > > > > > > > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn < > ptupit...@apache.org> > > > >>> wrote: > > > > > > > >> Igniters, > > > >> > > > >> I think we should plan 2.10 instead of 2.9.1. > > > >> ignite-2.9 branch was cut 4 months ago, a bunch of new features > are > > > > waiting > > > >> to be released. > > > >> > > > >> On Tue, Oct 27, 2020 at 4:23 AM 18624049226 < > 18624049...@163.com> > > > >>> wrote: > > > >> > > > >>> Hello, > > > >>> > > > >>> I suggest that the remaining document issue in version 2.9.0 > can > > > >> be > > > >>> solved in version 2.9.1, and it is not a good practice to > > > >> postpone > > > >>> to > > > >>> version 2.10. > > > >>> > > > >>> 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > > Hello, > > > > > > +1 > > > Should we start the discussion about the release leader and > > > >>> release > > > >>> dates? > > > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > > > > > wrote: > > > > +1 to start the 2.9.1 release process once as soon as 2.9 > > > >>> released. > > > > > > > > On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > > > > nizhi...@apache.org> > > > >>> wrote: > > > > > > > >> Hello, Yaroslav. > > > >> > > > >> I support the idea. > > > >> But, we should carefully work with the release scope. > > > >> > > > >> IGNITE-13477 - fix for a SQL tracing that will be available > > > >>> only in > > > >>> 2.10 > > > >> IGNITE-13427 - fix for a new system view that exists in > > > >> master > > > > only, > > > >> we > > > >> need to include IGNITE-13409 > > > >> > > > >> Other tickets should be checked, also. > > > >> Is this a real fix of a released bug or we fix some issue we > > > >>> bring > > > >> with > > > >> the brand new contribution. > > > >> > > > >> > > > >> I propose to include the following tickets, also: > > > >> > > > >> CMD tools improvements: > > > >> > > > >> IGNITE-13488 - Command to print metric value > > > >> IGNITE-13426 - Command to print system view content > > > >> IGNITE-13422 - Parameter to explicitly enable experimental > > > >>> commands > > > >> > > > >> IGNITE-13380 - Output
Re: 2.9.1 release proposal
Folks, What may be the comfortable dates of the 2.10 release to finish all the related development activities? I suggest release Apache Ignite 2.10 prior to the end of this year and focus on the 3.0 activities in 2021 with only bug-fix releases for the 2.10.x. I suggest the following release dates for the 2.10: Code Freeze: December 16th, 2020 Release Date: December 30th, 2020 On Tue, 3 Nov 2020 at 18:15, Yaroslav Molochkov wrote: > > Nikolay, hi! > > Done. > > On Tue, Nov 3, 2020 at 10:48 AM Nikolay Izhikov wrote: > > > Hello, Yaroslav. > > > > Looks like we have fixVersion 2.9.1 in Jira. > > Let’s mark all tickets with label «2.9.1-rc1» with fixVersion=2.9.1 and > > use fixVersion instead of label further. > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 > > > > > 2 нояб. 2020 г., в 19:42, Yaroslav Molochkov > > написал(а): > > > > > > Guys, > > > > > > should you agree that issues with the 2.9.1-rc tag are good enough > > > for a maintenance release, i'd like to give it a go. > > > > > > On Thu, Oct 29, 2020 at 5:33 PM Alexey Zinoviev > > > wrote: > > > > > >> Let's discuss the possible planning dates for feature freeze for 2.10, > > for > > >> example? Do you have any plans or ideas? > > >> > > >> чт, 29 окт. 2020 г. в 17:24, Andrey Gura : > > >> > > >>> Hi, > > >>> > > >>> I agree with Alexey. We should release 2.9.1 and start preparing for > > >>> the 2.10 release. > > >>> > > >>> 2.x releases usually take a lot of time. So we can release 2.9.1, and > > >>> even 2.9.2 before 2.10. > > >>> > > >>> On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk > > >>> wrote: > > > > Hello folks, > > > > I think we should start both 2.9.1 and 2.10. In practice, maintenance > > release contains only critical and usability bugfixes (for example, I > > >>> would > > include this ticket [1] to include in 2.9.1 as it prevents users from > > >>> using > > tracing) and is released much faster than a minor release. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13640 > > > > вт, 27 окт. 2020 г. в 21:41, Guru Stron : > > > > > Hello, > > > > > > Agree with Pavel. > > > > > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn > > >>> wrote: > > > > > >> Igniters, > > >> > > >> I think we should plan 2.10 instead of 2.9.1. > > >> ignite-2.9 branch was cut 4 months ago, a bunch of new features are > > > waiting > > >> to be released. > > >> > > >> On Tue, Oct 27, 2020 at 4:23 AM 18624049226 <18624049...@163.com> > > >>> wrote: > > >> > > >>> Hello, > > >>> > > >>> I suggest that the remaining document issue in version 2.9.0 can > > >> be > > >>> solved in version 2.9.1, and it is not a good practice to > > >> postpone > > >>> to > > >>> version 2.10. > > >>> > > >>> 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > Hello, > > > > +1 > > Should we start the discussion about the release leader and > > >>> release > > >>> dates? > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > > > wrote: > > > +1 to start the 2.9.1 release process once as soon as 2.9 > > >>> released. > > > > > > On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > > > nizhi...@apache.org> > > >>> wrote: > > > > > >> Hello, Yaroslav. > > >> > > >> I support the idea. > > >> But, we should carefully work with the release scope. > > >> > > >> IGNITE-13477 - fix for a SQL tracing that will be available > > >>> only in > > >>> 2.10 > > >> IGNITE-13427 - fix for a new system view that exists in > > >> master > > > only, > > >> we > > >> need to include IGNITE-13409 > > >> > > >> Other tickets should be checked, also. > > >> Is this a real fix of a released bug or we fix some issue we > > >>> bring > > >> with > > >> the brand new contribution. > > >> > > >> > > >> I propose to include the following tickets, also: > > >> > > >> CMD tools improvements: > > >> > > >> IGNITE-13488 - Command to print metric value > > >> IGNITE-13426 - Command to print system view content > > >> IGNITE-13422 - Parameter to explicitly enable experimental > > >>> commands > > >> > > >> IGNITE-13380 - Output IgniteSystemProperties via ignite.sh > > >> > > >> New system views: > > >> > > >> IGNITE-13409 Metastorage and DistributedMetastorage viewы. > > >> IGNITE-13408 BinaryMetadata view. > > >> > > >> > > >>> 19 окт. 2020 г., в 18:20, Yaroslav Molochkov < > > > molochko...@gmail.com > > >>> > > >> написал(а): > > >>> Hello, Igniters! > > >>> > > >>> I've compiled a list of
[jira] [Created] (IGNITE-13675) Devnotes in C++ platforms pointed that windows cmake not yet supported
Stepan Pilschikov created IGNITE-13675: -- Summary: Devnotes in C++ platforms pointed that windows cmake not yet supported Key: IGNITE-13675 URL: https://issues.apache.org/jira/browse/IGNITE-13675 Project: Ignite Issue Type: Bug Components: documentation, platforms Reporter: Stepan Pilschikov Currently in devnotes written that windows cmake not yet supported which is wrong https://github.com/apache/ignite/blob/b986cf6f2250858b92e4eda52f9269077659229c/modules/platforms/cpp/DEVNOTES.txt#L11 -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Ignite 3.0 development approach
Folks, Should we perform cleanup work before (r)evolutional changes? My huge proposal is to get rid of things which we don't need anyway - local caches, - strange tx modes, - code overcomplexity because of RollingUpgrade feature never attended at AI, - etc, before choosing the way. On Tue, Nov 3, 2020 at 3:31 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Ksenia, thanks for scheduling this on such short notice! > > As for the original topic, I do support Alexey's idea. We're not going to > rewrite anything from scratch, as most of the components are going to be > moved as-is or with minimal modifications. However, the changes that are > proposed imply serious rework of the core parts of the code, which are not > properly decoupled from each other and from other parts. This makes the > incremental approach borderline impossible. Developing in a new repo, > however, addresses this concern. As a bonus, we can also refactor the code, > introduce better decoupling, get rid of kernel context, and develop unit > tests (finally!). > > Basically, this proposal only affects the *process*, not the set of changes > we had discussed before. Ignite 3.0 is our unique chance to make things > right. > > -Val > > On Tue, Nov 3, 2020 at 3:06 AM Kseniya Romanova > > wrote: > > > Pavel, all the interesting points will be anyway published here in > English > > (as the principal "if it's not on devlist it doesn't happened" is still > > relevant). This is just a quick call for a group of developers. Later we > > can do a separate presentation of idea and discussion in English as we > did > > for the Ignite 3.0 draft of changes. > > > > вт, 3 нояб. 2020 г. в 13:52, Pavel Tupitsyn : > > > > > Kseniya, > > > > > > Thanks for scheduling this call. > > > Do you think we can switch to English if non-Russian speaking community > > > members decide to join? > > > > > > On Tue, Nov 3, 2020 at 1:32 PM Kseniya Romanova < > > romanova.ks@gmail.com > > > > > > > wrote: > > > > > > > Let's do this community discussion open. Here's the link on zoom call > > in > > > > Russian for Friday 6 PM: > > > > https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/274360378/ > > > > > > > > вт, 3 нояб. 2020 г. в 12:49, Nikolay Izhikov : > > > > > > > > > Time works for me. > > > > > > > > > > > 3 нояб. 2020 г., в 12:40, Alexey Goncharuk < > > > alexey.goncha...@gmail.com > > > > > > > > > > написал(а): > > > > > > > > > > > > Nikolay, > > > > > > > > > > > > I am up for the call. I will try to explain my reasoning in > greater > > > > > detail > > > > > > and will be glad to hear the concerns. Will this Friday, Nov 6th, > > > work? > > > > > > > > > > > > вт, 3 нояб. 2020 г. в 10:09, Nikolay Izhikov < > nizhi...@apache.org > > >: > > > > > > > > > > > >> Igniters, should we have a call for this topic? > > > > > >> > > > > > >>> 2 нояб. 2020 г., в 18:53, Pavel Tupitsyn > > > > > > >> написал(а): > > > > > >>> > > > > > not intend to rewrite everything from scratch > > > > > >>> > > > > > Every single test from Ignite 2.x should be moved to Ignite 3 > > > > > regardless of how we choose to proceed. > > > > > >>> > > > > > >>> Alexey, thank you for the explanation, this addresses all of my > > > > > concerns. > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> On Mon, Nov 2, 2020 at 6:43 PM Andrey Mashenkov < > > > > > >> andrey.mashen...@gmail.com> > > > > > >>> wrote: > > > > > >>> > > > > > Hi, Igniters. > > > > > > > > > > * AFAIU, we need a new repo if we want to apply different > > > > restrictions > > > > > >> to > > > > > pull requests, > > > > > otherwise I see no difference for myself. > > > > > E.g. make static analysis (do we have?), compile, styles, and > > > > javadoc > > > > > checks mandatory. > > > > > > > > > > I think that relaxed requirements here will lead to bad > product > > > > > quality. > > > > > > > > > > * Agree with Pavel, we should 'keep' integrations tests > somehow. > > > > > During active development tests will be broken most of time, > so, > > > > > I'd port them e.g. suite-by-suite once we will have a stable > and > > > > > >> featured > > > > > environment to run them and of course make test's code clear > and > > > > avoid > > > > > bad/non-relevant ones. > > > > > > > > > > * I like bottom-up approach. > > > > > With it we could make a better framework. I mean clear > component > > > > > >> lifecycle, > > > > > component wiring mechanics, general methods to approach core > > > > > components > > > > > such as exchange/communication > > > > > to avoid code mess like we have in ExchangeFuture with all > these > > > > > custom > > > > > callbacks for each component, interfaces like > > > > > PartitionsExchangeAware, IgniteChangeGlobalStateSupport and > > > > > a pack of > > > > > >>
Re: [DISCUSS] Disable socket linger by default in TCP discovery SPI.
Folks, Seems, we've got an agreement that the fix is necessary. Do we need to do except the following? >> zero linger as default + warning on SSL enabled on JVM before the fix + warning at documentation + migration notes On Tue, Nov 3, 2020 at 2:38 PM Steshin Vladimir wrote: > Ilya, hi. > > > Of course: /TcpDiscoverySpi.setSoLinger(int)/ property. Always been. > > > 02.11.2020 20:14, Ilya Kasnacheev пишет: > > Hello! > > > > Is there any option to re-enable linger on SSL sockets? > > > > Telling people to re-configure does not help if they can't. > > > > Regards, >
