Re: Apache Ignite 2.16 RELEASE [Time, Scope, Manager]
Hi Nikita, Is it possible to add the following ticket to the scope of the release as well? https://issues.apache.org/jira/browse/IGNITE-21032 GitHub issue: https://github.com/apache/ignite/issues/11045 Thanks, S. пн, 4 дек. 2023 г. в 21:13, Nikita Amelchev : > Hello, Igniters. > > I had a private conversation with Nikolay Izhikov and Maksim Timonin. > I propose to include the realtime CDC back into the 2.16 scope [1]. > And also a couple of important tickets related to the cache dumps > [2-4]. > > They need an extra week of time to merge it. > > Any objections? > > [1] https://issues.apache.org/jira/browse/IGNITE-17700 > [2] https://issues.apache.org/jira/browse/IGNITE-21013 > [3] https://issues.apache.org/jira/browse/IGNITE-20890 > [4] https://issues.apache.org/jira/browse/IGNITE-20614 > > пн, 27 нояб. 2023 г. в 17:18, Nikita Amelchev : > > > > Hello, Igniters. > > > > The release branch has been stabilized. I'm waiting for load tests. > > > > The RC will be prepared in the coming days. > > > > пн, 20 нояб. 2023 г. в 22:28, Nikita Amelchev : > > > > > > Hello, Igniters. > > > > > > I'm announcing a code freeze for the 2.16 release. Only blockers are > > > accepted to the release since this moment. > > > > > > пн, 13 нояб. 2023 г. в 19:13, Nikita Amelchev : > > > > > > > > Hello, Igniters. > > > > > > > > I suggest moving the code freeze date to +1 week. > > > > > > > > We have several bug fixes ready to be merged [1], for example: > > > > > > > > IGNITE-19239 Checkpoint read lock acquisition timeouts during > snapshot restore > > > > IGNITE-20816 In-memory server node is crashed by > > > > TcpIgniteClient.putAllConflict() if cache objects transformation > > > > applied > > > > > > > > Updated dates: > > > > > > > > Code Freeze: November 20, 2023 > > > > Voting Date: November 27, 2023 > > > > Release Date: December 4, 2023 > > > > > > > > [1] > https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.16%27))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20%20and%20status%20not%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20ORDER%20BY%20priority > > > > > > > > пн, 6 нояб. 2023 г. в 12:36, Nikita Amelchev : > > > > > > > > > > Hi, > > > > > > > > > > Yes, they are marked with the 2.16 fix version. According to the > > > > > release process they will be cherry-picked to the release branch if > > > > > merged before code freeze. > > > > > > > > > > Documentation issues can be cherry-picked regardless of these > dates. > > > > > > > > > > пн, 6 нояб. 2023 г. в 11:47, 李玉珏 <18624049...@163.com>: > > > > > > > > > > > > Hi, > > > > > > > > > > > > Can the following PR be included in the scope of 2.16.0 version? > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-10268 > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-18038 > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-18572 > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-19436 > > > > > > > > > > > > > > > > > > 在 2023/11/6 16:21, Nikita Amelchev 写道: > > > > > > > Igniters, > > > > > > > > > > > > > > I have cut the release branch: 'ignite-2.16'. Please, > cherry-pick new > > > > > > > issues if needed. > > > > > > > > > > > > > > The 2.16 scope is frozen. Unresolved not-blocking issues will > be moved > > > > > > > on the code freeze stage. > > > > > > > > > > > > > > Code freeze is planned for November 13, 2023. Please, feel > free to > > > > > > > write if some issues are critical to be in the 2.16. > > > > > > > > > > > > > > ср, 25 окт. 2023 г. в 15:00, Nikita Amelchev< > namelc...@apache.org>: > > > > > > >> Hello Igniters, > > > > > > >> > > > > > > >> I have created the 2.16 release page [1]. > > > > > > >> > > > > > > >> Also, I propose to cut the release branch on the scope freeze > day > > > > > > >> (November 6, 2023). > > > > > > >> > > > > > > >> [1] > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.16 > > > > > > >> > > > > > > >> вт, 24 окт. 2023 г. в 19:13, Dmitriy Pavlov< > dpav...@apache.org>: > > > > > > >>> +1, fully support Nikita to be RM > > > > > > >>> > > > > > > >>> > > > > > > >>> пн, 23 окт. 2023 г. в 13:29, Pavel Tupitsyn< > ptupit...@apache.org>: > > > > > > >>> > > > > > > Sounds good, new JDK support seems to be in demand. > > > > > > > > > > > > On Mon, Oct 23, 2023 at 12:20 PM Anton Vinogradov< > a...@apache.org> wrote: > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > On Sun, Oct 22, 2023 at 12:29 PM Nikita Amelchev< > namelc...@apache.org> > > > > > > > wrote: > > > > > > > > > > > > > >> Dear Ignite Community! > > > > > > >> > > > > > > >> I suggest starting Apache Ignite 2.16 release activities. > > > > > > >> > > > > > > >> We've accumulated a hundred resolved [1] issues with new > features and > > > > > > >> bug fixes which are waiting
Re: New Apache Ignite PMC member: Nikita Amelchev
Congratulations, Nikita! Thanks, S. ср, 22 нояб. 2023 г. в 18:55, Ivan Daschinsky : > Congratulations, you deserve it > > On Wed, Nov 22, 2023, 18:10 Nikita Amelchev wrote: > > > Thank you everyone, I'm very pleased! > > > > ср, 22 нояб. 2023 г. в 15:46, Ilya Shishkov : > > > > > > Congratulations, Nikita! > > > > > > ср, 22 нояб. 2023 г. в 14:53, Maksim Timonin >: > > > > > > > > Congratulations! > > > > > > > > On Wed, Nov 22, 2023 at 2:29 PM Anton Vinogradov > > wrote: > > > > > > > > > Welcome aboard :) > > > > > > > > > > On Wed, Nov 22, 2023 at 2:11 PM Maxim Muzafarov > > > wrote: > > > > > > > > > > > My congratulations, Nikita! > > > > > > > > > > > > On Tue, 21 Nov 2023 at 15:20, Dmitriy Pavlov > > > wrote: > > > > > > > > > > > > > > Hello Igniters, > > > > > > > > > > > > > > The Project Management Committee (PMC) for Apache Ignite > > > > > > > has invited Nikita Amelchev to become a member of PMC and we > are > > > > > pleased > > > > > > > to announce that he has accepted. > > > > > > > > > > > > > > We appreciate his constant efforts in improving Apache Ignite > > code, as > > > > > > well > > > > > > > as efforts in preparing 2 major releases. > > > > > > > > > > > > > > A PMC member helps manage and guide the direction of the > project. > > > > > > > > > > > > > > Congratulations on your new role! Keep the pace! > > > > > > > > > > > > > > Best Regards > > > > > > > Dmitriy Pavlov > > > > > > > on behalf of Apache Ignite PMC > > > > > > > > > > > > > > > > > > > -- > > Best wishes, > > Amelchev Nikita > > >
Re: [ANNOUNCE] Welcome Stephen Darlington as a new committer
Well deserved! Three cheers for you, Stephen! Thanks, S. пн, 4 сент. 2023 г. в 12:38, Wei Cheng <29608336...@gmail.com>: > > Congratulations > > Thanks > Wei Cheng > > > 在 2023年9月4日，17:28，ZhangJian He 写道： > > > > Configurations! > > > > Thanks > > ZhangJian He > > > > > >> On Mon, 4 Sept 2023 at 17:24, Kseniya Romanova > >> wrote: > >> > >> Igniters! > >> > >> The Project Management Committee (PMC) for Apache Ignite has invited > >> Stephen > >> Darlington to become a committer and we are pleased to announce that he > has > >> accepted. > >> > >> Stephen made several valuable code contributions and he participates > >> actively in discussions about Apache Ignite development, but he’s best > >> known as a dedicated mentor for those developers who are just starting > >> their exciting Ignite journey! Stephen answers their questions on the > user > >> list and SOF, supports free Ignite learning sessions as a trainer and > >> several times was a host of the community main events - Ignite Summit. > >> > >> And I'm sure you agree with me that all of the above is an invaluable > >> contribution to the Apache Ignite community! > >> > >> Please join me in welcoming Stephen, and congratulating him on the new > role > >> in the Apache Ignite Community! > >> > >> Kseniya Romanova > >> > >> on behalf of Apache Ignite PMC > >> >
Re: TX code cleanup (MVCC removal)
Hi, all tickets are closed. Thanks, S. ср, 23 авг. 2023 г. в 19:05, Anton Vinogradov : > MVCC test/suites removal PR was merged. > > Slava, > > I think it would be nice to close (with "will not fix" status) all open > > tickets related to MVCC > > Great idea. > Could I ask you to do this? > > On Wed, Aug 23, 2023 at 6:16 PM Вячеслав Коптилин < > slava.kopti...@gmail.com> > wrote: > > > Hi Anton, > > > > +1 for removal MVCC > > > > I think it would be nice to close (with "will not fix" status) all open > > tickets related to MVCC: > > > > > https://issues.apache.org/jira/browse/IGNITE-12118?jql=project%20%3D%20IGNITE%20AND%20resolution%20%3D%20Unresolved%20%20and%20summary%20~%20%22MVCC%22%20ORDER%20BY%20%20priority%20DESC%2C%20updated%20DESC > > > > WDYT? > > > > Thanks, > > Slava. > > > > вт, 22 авг. 2023 г. в 22:03, Anton Vinogradov : > > > > > Going to merge on green visa obtaining if there are no objections. > > > > > > On Tue, Aug 22, 2023 at 6:47 PM Anton Vinogradov > wrote: > > > > > > > MVCC test/suites removal PR [1] is almost ready, fixing final > failures. > > > > > > > > Does anybody ready to review the PR? > > > > > > > > I've rechecked each modified line before pushing the commit button, > is > > > > this enough? > > > > > > > > [1] https://github.com/apache/ignite/pull/10900 > > > > > > > > On Thu, Aug 17, 2023 at 1:18 PM Anton Vinogradov > > wrote: > > > > > > > >> Great, starting the removal. > > > >> > > > >> On Wed, Aug 16, 2023 at 5:35 PM Ivan Daschinsky < > ivanda...@gmail.com> > > > >> wrote: > > > >> > > > >>> The plan looks good to me. Some of the tests are in the ODBC test > > > suite, > > > >>> so > > > >>> i can help if needed. > > > >>> > > > >>> ср, 16 авг. 2023 г. в 16:32, Anton Vinogradov : > > > >>> > > > >>> > Igniters, > > > >>> > > > > >>> > I started the TX code cleanup [1] last month and almost finished > > with > > > >>> the > > > >>> > obvious garbage. > > > >>> > Now, started the code deduplication, I was faced with code > > > >>> overcomplexity > > > >>> > because of unfinished MVCC. > > > >>> > > > > >>> > The community agreed to remove MVCC, but the initial attempt [2] > > was > > > >>> not > > > >>> > successful because of the impossibility to get rid of 20k+ lines > of > > > the > > > >>> > code at once. > > > >>> > So, my proposal is to remove it step by step. > > > >>> > > > > >>> > 1) MVCC tests should be removed from the project > > > >>> > 2) MVCC-related code should be removed from the project by > > reasonably > > > >>> sized > > > >>> > commits, checking it does not affect the existing tests. > > > >>> > > > > >>> > I'm ready to perform the removal. > > > >>> > > > > >>> > Any objections/tips? > > > >>> > > > > >>> > [1] https://issues.apache.org/jira/browse/IGNITE-19844 > > > >>> > [2] https://issues.apache.org/jira/browse/IGNITE-13871 > > > >>> > > > > >>> > > > >>> > > > >>> -- > > > >>> Sincerely yours, Ivan Daschinskiy > > > >>> > > > >> > > > > > >
Re: TX code cleanup (MVCC removal)
Hello Anton, Hmm, I am a bit confused, to be honest. IMHO, this simple JIRA cleanup could be done under https://issues.apache.org/jira/browse/IGNITE-13871 which is assigned to you. Is it required to delegate? Best regards, S. ср, 23 авг. 2023 г. в 19:05, Anton Vinogradov : > MVCC test/suites removal PR was merged. > > Slava, > > I think it would be nice to close (with "will not fix" status) all open > > tickets related to MVCC > > Great idea. > Could I ask you to do this? > > On Wed, Aug 23, 2023 at 6:16 PM Вячеслав Коптилин < > slava.kopti...@gmail.com> > wrote: > > > Hi Anton, > > > > +1 for removal MVCC > > > > I think it would be nice to close (with "will not fix" status) all open > > tickets related to MVCC: > > > > > https://issues.apache.org/jira/browse/IGNITE-12118?jql=project%20%3D%20IGNITE%20AND%20resolution%20%3D%20Unresolved%20%20and%20summary%20~%20%22MVCC%22%20ORDER%20BY%20%20priority%20DESC%2C%20updated%20DESC > > > > WDYT? > > > > Thanks, > > Slava. > > > > вт, 22 авг. 2023 г. в 22:03, Anton Vinogradov : > > > > > Going to merge on green visa obtaining if there are no objections. > > > > > > On Tue, Aug 22, 2023 at 6:47 PM Anton Vinogradov > wrote: > > > > > > > MVCC test/suites removal PR [1] is almost ready, fixing final > failures. > > > > > > > > Does anybody ready to review the PR? > > > > > > > > I've rechecked each modified line before pushing the commit button, > is > > > > this enough? > > > > > > > > [1] https://github.com/apache/ignite/pull/10900 > > > > > > > > On Thu, Aug 17, 2023 at 1:18 PM Anton Vinogradov > > wrote: > > > > > > > >> Great, starting the removal. > > > >> > > > >> On Wed, Aug 16, 2023 at 5:35 PM Ivan Daschinsky < > ivanda...@gmail.com> > > > >> wrote: > > > >> > > > >>> The plan looks good to me. Some of the tests are in the ODBC test > > > suite, > > > >>> so > > > >>> i can help if needed. > > > >>> > > > >>> ср, 16 авг. 2023 г. в 16:32, Anton Vinogradov : > > > >>> > > > >>> > Igniters, > > > >>> > > > > >>> > I started the TX code cleanup [1] last month and almost finished > > with > > > >>> the > > > >>> > obvious garbage. > > > >>> > Now, started the code deduplication, I was faced with code > > > >>> overcomplexity > > > >>> > because of unfinished MVCC. > > > >>> > > > > >>> > The community agreed to remove MVCC, but the initial attempt [2] > > was > > > >>> not > > > >>> > successful because of the impossibility to get rid of 20k+ lines > of > > > the > > > >>> > code at once. > > > >>> > So, my proposal is to remove it step by step. > > > >>> > > > > >>> > 1) MVCC tests should be removed from the project > > > >>> > 2) MVCC-related code should be removed from the project by > > reasonably > > > >>> sized > > > >>> > commits, checking it does not affect the existing tests. > > > >>> > > > > >>> > I'm ready to perform the removal. > > > >>> > > > > >>> > Any objections/tips? > > > >>> > > > > >>> > [1] https://issues.apache.org/jira/browse/IGNITE-19844 > > > >>> > [2] https://issues.apache.org/jira/browse/IGNITE-13871 > > > >>> > > > > >>> > > > >>> > > > >>> -- > > > >>> Sincerely yours, Ivan Daschinskiy > > > >>> > > > >> > > > > > >
Re: TX code cleanup (MVCC removal)
Hi Anton, +1 for removal MVCC I think it would be nice to close (with "will not fix" status) all open tickets related to MVCC: https://issues.apache.org/jira/browse/IGNITE-12118?jql=project%20%3D%20IGNITE%20AND%20resolution%20%3D%20Unresolved%20%20and%20summary%20~%20%22MVCC%22%20ORDER%20BY%20%20priority%20DESC%2C%20updated%20DESC WDYT? Thanks, Slava. вт, 22 авг. 2023 г. в 22:03, Anton Vinogradov : > Going to merge on green visa obtaining if there are no objections. > > On Tue, Aug 22, 2023 at 6:47 PM Anton Vinogradov wrote: > > > MVCC test/suites removal PR [1] is almost ready, fixing final failures. > > > > Does anybody ready to review the PR? > > > > I've rechecked each modified line before pushing the commit button, is > > this enough? > > > > [1] https://github.com/apache/ignite/pull/10900 > > > > On Thu, Aug 17, 2023 at 1:18 PM Anton Vinogradov wrote: > > > >> Great, starting the removal. > >> > >> On Wed, Aug 16, 2023 at 5:35 PM Ivan Daschinsky > >> wrote: > >> > >>> The plan looks good to me. Some of the tests are in the ODBC test > suite, > >>> so > >>> i can help if needed. > >>> > >>> ср, 16 авг. 2023 г. в 16:32, Anton Vinogradov : > >>> > >>> > Igniters, > >>> > > >>> > I started the TX code cleanup [1] last month and almost finished with > >>> the > >>> > obvious garbage. > >>> > Now, started the code deduplication, I was faced with code > >>> overcomplexity > >>> > because of unfinished MVCC. > >>> > > >>> > The community agreed to remove MVCC, but the initial attempt [2] was > >>> not > >>> > successful because of the impossibility to get rid of 20k+ lines of > the > >>> > code at once. > >>> > So, my proposal is to remove it step by step. > >>> > > >>> > 1) MVCC tests should be removed from the project > >>> > 2) MVCC-related code should be removed from the project by reasonably > >>> sized > >>> > commits, checking it does not affect the existing tests. > >>> > > >>> > I'm ready to perform the removal. > >>> > > >>> > Any objections/tips? > >>> > > >>> > [1] https://issues.apache.org/jira/browse/IGNITE-19844 > >>> > [2] https://issues.apache.org/jira/browse/IGNITE-13871 > >>> > > >>> > >>> > >>> -- > >>> Sincerely yours, Ivan Daschinskiy > >>> > >> >
Re: [ANNOUNCE] Welcome Aleksandr Polovtsev as a new committer
Congratulations, Alexander! Keep it up! Thanks, S. пн, 21 авг. 2023 г. в 09:14, Roman Puchkovskiy : > Congratulations! > > пн, 21 авг. 2023 г. в 09:29, Pavel Tupitsyn : > > > > Congratulations, Aleksandr! Well deserved! > > > > On Mon, Aug 21, 2023 at 8:01 AM Kseniya Romanova > > wrote: > > > > > Igniters! > > > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > > Aleksandr > > > Polovtsev to become a committer and we are pleased to announce that he > has > > > accepted. > > > > > > Alexandr makes valuable contributions to the Apache Ignite code > (including > > > Node Join Protocol and Initialization[1] for the Ignite 3), > participates in > > > important dev discussions and contributes as well to the Project > awareness > > > by presenting twice at the Ignite Summit[2] > > > > > > Please join me in welcoming Alexandr, and congratulating him on the new > > > role in the Apache Ignite Community! > > > > > > > > > Kseniya Romanova > > > > > > on behalf of Apache Ignite PMC > > > > > > [1] > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-77%3A+Node+Join+Protocol+and+Initialization+for+Ignite+3 > > > > > > > > > [2] https://ignite-summit.org/2023-june/sessions/484805 > > > https://ignite-summit.org/2022-june/sessions/337234 > > > >
Re: [DISCUSSION] Removing IgniteCacheSnapshotManager
Hello, I don't have any objections. Let's clean up the code. Thanks, Slava. вт, 4 июл. 2023 г. в 19:47, Николай Ижиков : > Hello, Igniters. > > IgniteCacheSnapshotManager is internal component that was deprecated more > then 3 years for now. > I have plans to remove it from codebase. > Is there any objections?
Re: Apache Ignite 2.15 RELEASE [Time, Scope, Manager]
+1 ср, 29 мар. 2023 г. в 21:57, Alex Plehanov : > Dear Ignite Community! > > I suggest starting Apache Ignite 2.15 release activities. > > We've accumulated more than two hundred resolved issues [1] with new > features and bug fixes which are waiting for release. > The major changes related to the proposed release: > - Incremental snapshots. > - Java thin client improvements (logging, connections balancing, > events listening, endpoints discovery) > - Calcite based SQL engine improvements (memory quotas, index scans > optimisations). > - Reworked permission management for system tasks. > - Removed some deprecated functionality (daemon nodes, visorcmd, legacy JMX > beans) > etc. > > I want to propose myself to be the release manager of the planning release. > > I propose the following timeline: > > Scope Freeze: April 08, 2023 > Code Freeze: April 15, 2023 > Voting Date: April 22, 2023 > Release Date: April 29, 2023 > > [1]. > > https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20in%20(2.15))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27) > > WDYT? >
Re: [VOTE] Release bug fix release pyignite-0.6.1-rc0
+1
ср, 15 февр. 2023 г. в 10:21, Ivan Daschinsky :
> Dear Igniters!
>
> This is a patch release that contains an important fix for users of
> pyignite
>
> https://issues.apache.org/jira/browse/IGNITE-18788
>
>
> Release candidate binaries for subj are uploaded and ready for vote
> You can find them here:
> https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.6.1-rc0
>
> If you follow the link above, you will find source packages (*.tar.gz and
> *.zip)
> and binary packages (wheels) for windows (amd64), linux (x86_64) amd mac os
> (x86_64)
> for pythons 37, 38, 39, 310 and 311. Also, there are sha512 and gpg
> signatures.
> Code signing keys can be found here -- https://downloads.apache.org/ignite
> /KEYS
> Here you can find instructions how to verify packages
> https://www.apache.org/info/verification.html
>
> You can install binary package for specific version of python using pip
> For example do this on linux for python 3.8
> >> pip install
>
> pyignite-0.6.1-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl
>
> You can build and install package from source using this command:
> >> pip install pyignite-0.6.1.zip
> You can build wheel on your platform using this command:
> >> pip wheel --no-deps pyignite-0.6.1.zip
>
> For building C module, you should have python headers and C compiler
> installed.
> (i.e. for ubuntu sudo apt install build-essential python3-dev)
> In Mac OS X xcode-tools and python from homebrew are the best option.
>
> In order to check whether C module works, use following:
> >> from pyignite import _cutils
> >> print(_cutils.hashcode('test'))
> >> 3556498
>
> You can find documentation here:
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.1.rc0/
>
> You can find examples here (to check them, you should start ignite
> locally):
>
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.1.rc0/examples.html
> Also, examples can be found in source archive in examples subfolder.
> docker-compose.yml is supplied in order to start ignite quickly. (Use
> `docker-compose up -d` to start 3 nodes cluster and `docker-compose
> down` to shut down it)
>
> Release notes:
>
> https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=blob;f=RELEASE_NOTES.txt;h=86448e9ce51d7223ac49cf4f95da70d3d365e8c1;hb=0d86f44e86270f4d578afbce41aa2d6c424d2615
>
> Git release tag was created:
>
> https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=tag;h=b0ce094d7a2db3fb07471be7b37ff9edab4180a8
>
> The vote is formal, see voting guidelines
> https://www.apache.org/foundation/voting.html
>
> +1 - to accept pyignite-0.6.1-rc0
> 0 - don't care either way
> -1 - DO NOT accept pyignite-0.6.1-rc0
>
> The vote finishes at 02/17/2021 15:00 UTC
>
> --
> Sincerely yours, Ivan Daschinskiy
>
Re: [VOTE] Release Extensions Ignite Spark 2.0.0 RC1, Ignite Spark 3.0.0 RC1
+1 пн, 12 дек. 2022 г. в 14:35, Pavel Tupitsyn : > +1 (binding) > > On Mon, Dec 12, 2022 at 2:34 PM Maxim Muzafarov wrote: > > > +1 > > > > On Mon, 12 Dec 2022 at 09:59, Andrey Gura wrote: > > > > > > +1 > > > > > > On Fri, Dec 9, 2022 at 10:36 AM Nikita Amelchev > > wrote: > > > > > > > > +1 > > > > > > > > Checked compilation, ran some examples. > > > > > > > > пт, 9 дек. 2022 г. в 03:53, Alexandr Shapkin : > > > > > > > > > > Dear Community, > > > > > > > > > > > > > > > The release candidates are ready. > > > > > > > > > > These are new Ignite Spark integrations based on Spark 2.4 and 3.2 > > dependencies respectively. > > > > > > > > > > > > > > > See the links below. > > > > > > > > > > > > > > > == Ignite Spark Extension Module 2.0.0 == > > > > > > > > > > The release candidate is uploaded to: > > > > > > > > https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-spark-ext-2.0.0-rc1/ > > > > > > > > > > The following Maven staging can be used: > > > > > > > > https://repository.apache.org/content/repositories/orgapacheignite-1557/org/apache/ignite/ignite-spark-ext/ > > > > > > > > > > Tag: > > > > > > > > https://github.com/apache/ignite-extensions/releases/tag/ignite-spark-ext-2.0.0-rc1 > > > > > > > > > > RELEASE_NOTES: > > > > > > > > https://github.com/apache/ignite-extensions/blob/release/ignite-spark-ext-2.0.0/modules/spark-ext/spark/RELEASE_NOTES.txt > > > > > > > > > > DEVNOTES: > > > > > > > > https://github.com/apache/ignite-extensions/blob/release/ignite-spark-ext-2.0.0/DEVNOTES.md > > > > > > > > > > Release Checker Results: > > > > > > https://github.com/apache/ignite-extensions/actions/runs/3652976657 > > > > > > > > > > > > > > > > > > > > == Ignite Spark Extension Module 3.0.0 == > > > > > > > > > > The release candidate is uploaded to: > > > > > > > > https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-spark-ext-3.0.0-rc1/ > > > > > > > > > > The following Maven staging can be used: > > > > > > > > https://repository.apache.org/content/repositories/orgapacheignite-1557/org/apache/ignite/ignite-spark-ext/ > > > > > > > > > > Tag: > > > > > > > > https://github.com/apache/ignite-extensions/releases/tag/ignite-spark-ext-3.0.0-rc1 > > > > > > > > > > RELEASE_NOTES: > > > > > > > > https://github.com/apache/ignite-extensions/blob/release/ignite-spark-ext-3.0.0/modules/spark-ext/spark/RELEASE_NOTES.txt > > > > > > > > > > DEVNOTES: > > > > > > > > https://github.com/apache/ignite-extensions/blob/release/ignite-spark-ext-3.0.0/DEVNOTES.md > > > > > > > > > > Release Checker Results: > > > > > > https://github.com/apache/ignite-extensions/actions/runs/3634524603 > > > > > > > > > > > > > > > > > > > > The vote is formal, see voting guidelines > > > > > https://www.apache.org/foundation/voting.html > > > > > > > > > > +1 - to accept (Ignite Spark 3.0.0 RC1, Ignite Spark 2.0.0 RC1) > > > > > 0 - don't care either way > > > > > -1 - DO NOT accept (explain why) > > > > > > > > > > See notes on how to verify release here > > > > > https://www.apache.org/info/verification.html > > > > > and > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification > > > > > > > > > > > > > > > This vote will be open for at least 72 hours till Mon Dec, 12 2022, > > 02:00 CET TZ. > > > > > Please, write down the thread if you need additional time to check > > the release. > > > > > > > > > > > > > > > > > -- > > > > Best wishes, > > > > Amelchev Nikita > > >
Re: Use AutoService library to generate Java SPI files in Ignite 3
Hi Aleksandr, This suggestion seems useful to me. As Aleksandr pointed out, this is a compile-time dependency, so it doesn't look risky. +1 Thanks, Slava. ср, 7 дек. 2022 г. в 10:20, Aleksandr Polovtsev : > Dear Igniters! In Ignite 3, we have a bunch of classes that utilize the > Java SPI (ConfigurationModule and MetricsExporter to name a few). For every > interface implementation we need to manually create a file in the META-INF > folder. This step can be automated by the AutoService library [1]. > > I can see the following pros and cons of using this approach: > 1. Pros: > * Less manual boilerplate, > * This is a compile-time only dependency (an annotation and an annotation > processor), > * Less files to maintain and update/move when corresponding interfaces > change. > 2. Cons: > * A new dependency will be introduced and it looks like the community > doesn't like that. > > I've created a PR [2] with a demonstration how this library can be used in > the existing code base. > > [1] https://github.com/google/auto/tree/main/service > [2] https://github.com/apache/ignite-3/pull/1415 > > -- > With regards, > Aleksandr Polovtsev >
Re: [DISCUSSION] Removal of ignitevisorcmd
Hi Igniters, I fully support the idea to stop supporting Visor and removing its implementation. However, do we have a list of useful features that do not exist in our control utility? Perhaps, it makes sense to reimplement such functionality and provide it based on control.sh script. Thanks, Slava. чт, 1 дек. 2022 г. в 15:51, Nikolay Izhikov : > PR is ready for review - https://github.com/apache/ignite/pull/10411 > > чт, 1 дек. 2022 г. в 16:49, Taras Ledkov : > > > Hi, > > > > +1 for remove Visor related code. > > Unfortunately we have to migrate `control-utility` to use IgniteClient > > (thin client) before drop GridClient. I guess we will do it in the > future. > > > > Also, the old thin JDBC based on the GridClient (classes placed at the > > org.apache.ignite.internal.jdbc.*) must be removed. > > >
[ANNOUNCE] Apache Ignite 3.0.0-beta1 is released
Dear Igniters, I'm happy to announce that the 1st beta version of Ignite 3 is out! On top of the functionality that was previously released, Beta 5 adds the following major features: - RPM and DEB packages: simplified installation and node management with system services. - Client's Partition Awareness: Clients are now aware of data distribution over the cluster nodes which helps avoid additional network transmissions and lowers operations latency. - C++ client: Basic C++ client, able to perform operations on data. - Autogenerated values: now a function can be specified as a default value generator during a table creation. Currently only gen_random_uuid is supported. - SQL Transactions. - Transactional Protocol: improved locking model, multi-version based lock-free read-only transactions. - Storage: A number of improvements to memory-only and on-disk engines based on Page Memory. - Indexes: Basic functionality, hash and sorted indexes. - Client logging: A LoggerFactory may be provided during client creation to specify a custom logger for logs generated by the client. - Metrics framework. Code examples have been added for the new features, you can check them out https://github.com/apache/ignite-3/tree/ignite-3.0.0-beta1/examples If there are any questions, issues, or thoughts, please do not hesitate to reply to this email. Ignite Community is welcoming any feedback and will consider it in future development. Thanks, S.
[RESULT][VOTE] Release Apache Ignite 3.0.0-beta1 RC2
Dear Igniters, Apache Ignite 3.0.0-beta1 RC2 has been accepted. 8 "+1" votes received: - Pavel Tupitsyn (binding) - Alexander Lapin - Denis Chudov - Vladislav Pyatkov - Yuriy Gerzhedovich - Igor Sapego (binding) - Mirza Aliev - Igor Gusev No "0" or "-1" votes. Vote thread: https://lists.apache.org/thread/lvx68hhj55bxc7yy0s0kxo37dcs6d4s2 Thanks, S.
[VOTE] Release Apache Ignite 3.0.0-beta1 RC2
Dear Community, Ignite 3 is moving forward and I think we're in a good spot to release the first beta version. In the last few months the following major features have been added: - RPM and DEB packages: simplified installation and node management with system services. - Client's Partition Awareness: Clients are now aware of data distribution over the cluster nodes which helps avoid additional network transmissions and lowers operations latency. - C++ client: Basic C++ client, able to perform operations on data. - Autogenerated values: now a function can be specified as a default value generator during a table creation. Currently only gen_random_uuid is supported. - SQL Transactions. - Transactional Protocol: improved locking model, multi-version based lock-free read-only transactions. - Storage: A number of improvements to memory-only and on-disk engines based on Page Memory. - Indexes: Basic functionality, hash and sorted indexes. - Client logging: A LoggerFactory may be provided during client creation to specify a custom logger for logs generated by the client. - Metrics framework: Collection and export of cluster metrics. I propose to release 3.0.0-beta1 with the features listed above. Release Candidate: https://dist.apache.org/repos/dist/dev/ignite/3.0.0-beta1-rc2/ Maven Staging: https://repository.apache.org/content/repositories/orgapacheignite-1556/ Tag: https://github.com/apache/ignite-3/tree/3.0.0-beta1-rc2 +1 - accept Apache Ignite 3.0.0-beta1 RC2 0 - don't care either way -1 - DO NOT accept Apache Ignite 3.0.0-beta1 RC2 (explain why) Voting guidelines: https://www.apache.org/foundation/voting.html How to verify the release: https://www.apache.org/info/verification.html The vote will be closed on Wednesday, 16 November 2022, 18:00:00 (UTC time) https://www.timeanddate.com/countdown/generic?iso=20221116T18=1440=Apache+Ignite+3.0.0-beta1+RC2=cursive=1 Thanks, S.
Re: [VOTE] Release Apache Ignite 3.0.0-beta1 RC1
Hello, It was decided to cancel this vote. We will prepare a new release candidate when IGNITE-1812 is resolved. Thanks, S. пт, 11 нояб. 2022 г. в 14:05, Stanislav Lukyanov : > We've spoken with Mikhail, Pavel, and Slava about this on IM, and it seems > we need to make a bunch of small changes. > I've summarised them here: > https://issues.apache.org/jira/browse/IGNITE-18129. > > In short, we need to make sure that all clients are published in the > repository. Java and .NET client will be published as their own artefacts. > C++ client is published as source code, and the sources are included into > the general src.zip. > > Thanks, > Stan > > > On 11 Nov 2022, at 11:34, Pavel Tupitsyn wrote: > > > > Slava, Stan - thoughts? > > I'll be glad to help with .NET, but what about missing sources and README > > issues? > > > > On Thu, Nov 10, 2022 at 4:00 PM Pavel Tupitsyn > wrote: > > > >> Stanislav, > >> > >>> Isn't nuget package enough for .NET ecosystem? > >> Isn't Maven enough for the Java ecosystem? I would say yes, but we still > >> include Java client binaries in the zip file. > >> > >> Anyway, I'm ok with NuGet-only binaries, but let's include them in the > set > >> of files for the vote, like we do in 2.x, so the package can be tested. > >> > >> On Thu, Nov 10, 2022 at 3:46 PM Stanislav Lukyanov < > stanlukya...@gmail.com> > >> wrote: > >> > >>> Pavel, > >>> > >>> Regarding .NET client binaries - do you mean .dll files? Do you think > >>> they should be a part of the .zip? The same .zip or a separate one? > Isn't > >>> nuget package enough for .NET ecosystem? > >>> > >>> Thanks, > >>> Stan > >>> > >>>> On 9 Nov 2022, at 19:55, Pavel Tupitsyn wrote: > >>>> > >>>> Also: > >>>> - Source code is missing (*src.zip files) > >>>> - .NET client binaries are missing in binary zips > >>>> > >>>> On Wed, Nov 9, 2022 at 7:51 PM Pavel Tupitsyn > >>> wrote: > >>>> > >>>>> -0.5 (binding) > >>>>> > >>>>> README.md contains a mix of "Alpha 5" and "Beta 1" > >>>>> > >>>>> On Wed, Nov 9, 2022 at 7:45 PM Вячеслав Коптилин < > >>> slava.kopti...@gmail.com> > >>>>> wrote: > >>>>> > >>>>>> Dear Community, > >>>>>> > >>>>>> Ignite 3 is moving forward and I think we're in a good spot to > >>> release the > >>>>>> first beta version. In the last few months the following major > >>> features > >>>>>> have been added: > >>>>>> - RPM and DEB packages: simplified installation and node management > >>> with > >>>>>> system services. > >>>>>> - Client's Partition Awareness: Clients are now aware of data > >>> distribution > >>>>>> over the cluster nodes which helps avoid additional network > >>> transmissions > >>>>>> and lowers operations latency. > >>>>>> - C++ client: Basic C++ client, able to perform operations on data. > >>>>>> - Autogenerated values: now a function can be specified as a default > >>> value > >>>>>> generator during a table creation. Currently only gen_random_uuid is > >>>>>> supported. > >>>>>> - SQL Transactions. > >>>>>> - Transactional Protocol: improved locking model, multi-version > based > >>>>>> lock-free read-only transactions. > >>>>>> - Storage: A number of improvements to memory-only and on-disk > engines > >>>>>> based on Page Memory. > >>>>>> - Indexes: Basic functionality, hash and sorted indexes. > >>>>>> - Client logging: A LoggerFactory may be provided during client > >>> creation > >>>>>> to > >>>>>> specify a custom logger for logs generated by the client. > >>>>>> - Metrics framework: Collection and export of cluster metrics. > >>>>>> > >>>>>> I propose to release 3.0.0-beta1 with the features listed above. > >>>>>> > >>>>>> Release Candidate: > >>>>>> https://dist.apache.org/repos/dist/dev/ignite/3.0.0-beta1-rc1/ > >>>>>> Maven Staging: > >>>>>> > >>> > https://repository.apache.org/content/repositories/orgapacheignite-1555/ > >>>>>> Tag: https://github.com/apache/ignite-3/tree/3.0.0-beta1-rc1 > >>>>>> > >>>>>> +1 - accept Apache Ignite 3.0.0-alpha4 RC1 > >>>>>> 0 - don't care either way > >>>>>> -1 - DO NOT accept Apache Ignite 3.0.0-alpha4 RC1 (explain why) > >>>>>> > >>>>>> Voting guidelines: https://www.apache.org/foundation/voting.html > >>>>>> How to verify the release: > >>> https://www.apache.org/info/verification.html > >>>>>> > >>>>>> The vote will be closed on Tuesday, 15 November 2022, 12:00:00 (UTC > >>> time) > >>>>>> > >>>>>> > >>> > https://www.timeanddate.com/countdown/to?year=2022=11=15=12=0=0=utc-1 > >>>>>> > >>>>>> Thanks, > >>>>>> S. > >>>>>> > >>>>> > >>> > >>> > >
[VOTE] Release Apache Ignite 3.0.0-beta1 RC1
Dear Community, Ignite 3 is moving forward and I think we're in a good spot to release the first beta version. In the last few months the following major features have been added: - RPM and DEB packages: simplified installation and node management with system services. - Client's Partition Awareness: Clients are now aware of data distribution over the cluster nodes which helps avoid additional network transmissions and lowers operations latency. - C++ client: Basic C++ client, able to perform operations on data. - Autogenerated values: now a function can be specified as a default value generator during a table creation. Currently only gen_random_uuid is supported. - SQL Transactions. - Transactional Protocol: improved locking model, multi-version based lock-free read-only transactions. - Storage: A number of improvements to memory-only and on-disk engines based on Page Memory. - Indexes: Basic functionality, hash and sorted indexes. - Client logging: A LoggerFactory may be provided during client creation to specify a custom logger for logs generated by the client. - Metrics framework: Collection and export of cluster metrics. I propose to release 3.0.0-beta1 with the features listed above. Release Candidate: https://dist.apache.org/repos/dist/dev/ignite/3.0.0-beta1-rc1/ Maven Staging: https://repository.apache.org/content/repositories/orgapacheignite-1555/ Tag: https://github.com/apache/ignite-3/tree/3.0.0-beta1-rc1 +1 - accept Apache Ignite 3.0.0-alpha4 RC1 0 - don't care either way -1 - DO NOT accept Apache Ignite 3.0.0-alpha4 RC1 (explain why) Voting guidelines: https://www.apache.org/foundation/voting.html How to verify the release: https://www.apache.org/info/verification.html The vote will be closed on Tuesday, 15 November 2022, 12:00:00 (UTC time) https://www.timeanddate.com/countdown/to?year=2022=11=15=12=0=0=utc-1 Thanks, S.
[ANNOUNCE] CODE FREEZE for Apache Ignite 3.0.0 beta 1 Release
Hello Igniters, I would like to inform you that a code freeze started. Only blockers are accepted to be included to the scope. Thanks, Slava.
Re: [ANNOUNCE] SCOPE FREEZE for Apache Ignite 3.0.0 beta 1 RELEASE
Hello Mikhail, I agree that these tickets should be included in the release. Let's prepare corresponding pull-request(s). Thanks, Slava. пт, 28 окт. 2022 г. в 18:07, Mikhail Pochatkin : > Hello, I would like to add following tickets to ignite-3.0.0-beta1 > [IGNITE-17966] Fix problem with stuck Gradle processes in .NET tests - ASF > JIRA (apache.org) <https://issues.apache.org/jira/browse/IGNITE-17966> > [IGNITE-17965] Enable remote build cache for Gradle - ASF JIRA (apache.org > ) > <https://issues.apache.org/jira/browse/IGNITE-17965> > [IGNITE-17980] ./gradlew clean build -x test fails - ASF JIRA (apache.org) > <https://issues.apache.org/jira/browse/IGNITE-17980> > [IGNITE-18009] Fix gradle build - ASF JIRA (apache.org) > <https://issues.apache.org/jira/browse/IGNITE-18009> > > These tickets need to unblock problems with Gradle build and required for > packaging scope of beta1. Thanks! > > On Mon, Oct 24, 2022 at 10:27 PM Mikhail Pochatkin > > wrote: > > > Hello, Igniters. > > > > I want to point out that the current beta seems to be blocked by > > [IGNITE-17966] <https://issues.apache.org/jira/browse/IGNITE-17966>. The > > main problem is that we cannot enable Gradle build on CI at this moment, > > but we need it because all beta distributions are implemented via Gradle > > build. So, I am trying to fix it in a short time. > > > > On Sat, Oct 22, 2022 at 5:35 PM Stanislav Lukyanov < > stanlukya...@gmail.com> > > wrote: > > > >> There are 11 unresolved tickets in the scope now, 4 In Progress and 7 > >> Patch Available. > >> > >> I think we should try to set the code freeze according to the ticket > >> estimates instead of just setting it to the end of next week. I'll work > >> with each ticket owner to determine the critical path. > >> > >> I also saw an Open ticket that was added to the scope outside of the > >> process. I descoped it already, but we need to be careful of new tickets > >> being added to the scope. > >> > >> Thanks, > >> Stan > >> > >> > On 20 Oct 2022, at 15:59, Вячеслав Коптилин > > >> wrote: > >> > > >> > Hello Alexandr, > >> > > >> > Ok, I added these tickets to the scope. > >> > > >> > There are 12 tickets that are not resolved and included into the > scope. > >> So, > >> > we have to move the code freeze to the end of next week. > >> > > >> > Thanks, > >> > Slava. > >> > > >> > чт, 20 окт. 2022 г. в 08:36, Aleksandr Pakhomov : > >> > > >> >> Hi, Igniters. > >> >> > >> >> I would like to ask you to add a couple of tickets that are required > >> for > >> >> packaging: > >> >> > >> >> https://issues.apache.org/jira/browse/IGNITE-17781 < > >> >> https://issues.apache.org/jira/browse/IGNITE-17781> > >> >> https://issues.apache.org/jira/browse/IGNITE-17773 < > >> >> https://issues.apache.org/jira/browse/IGNITE-17773> > >> >> > >> >> These tickets are the last tickets in the packaging scope for beta1. > >> >> > >> >> -- > >> >> Best regards, > >> >> Aleksandr > >> >> > >> >>> On 19 Oct 2022, at 21:48, Вячеслав Коптилин < > slava.kopti...@gmail.com > >> > > >> >> wrote: > >> >>> > >> >>> Hi Yuriy, > >> >>> > >> >>> Let's add them. I hope that these three tasks are the last ones. > >> >>> > >> >>> Thanks, > >> >>> S. > >> >>> > >> >>> ср, 19 окт. 2022 г. в 16:41, Юрий : > >> >>> > >> >>>> Slava, thank you. > >> >>>> > >> >>>> During cherry picking one of aforementioned ticket was observed > >> >> dependency > >> >>>> on > >> >>>> https://issues.apache.org/jira/browse/IGNITE-17907 > >> >>>> https://issues.apache.org/jira/browse/IGNITE-17671 > >> >>>> https://issues.apache.org/jira/browse/IGNITE-17816 > >> >>>> > >> >>>> So, I propose adding them into the release scope. > >> >>>> > >> >>>> ср, 19 окт. 2022 г. в 15:53, Вячеслав Коптилин < > >> >> slava.
Re: [ANNOUNCE] SCOPE FREEZE for Apache Ignite 3.0.0 beta 1 RELEASE
Hello Alexandr, Ok, I added these tickets to the scope. There are 12 tickets that are not resolved and included into the scope. So, we have to move the code freeze to the end of next week. Thanks, Slava. чт, 20 окт. 2022 г. в 08:36, Aleksandr Pakhomov : > Hi, Igniters. > > I would like to ask you to add a couple of tickets that are required for > packaging: > > https://issues.apache.org/jira/browse/IGNITE-17781 < > https://issues.apache.org/jira/browse/IGNITE-17781> > https://issues.apache.org/jira/browse/IGNITE-17773 < > https://issues.apache.org/jira/browse/IGNITE-17773> > > These tickets are the last tickets in the packaging scope for beta1. > > -- > Best regards, > Aleksandr > > > On 19 Oct 2022, at 21:48, Вячеслав Коптилин > wrote: > > > > Hi Yuriy, > > > > Let's add them. I hope that these three tasks are the last ones. > > > > Thanks, > > S. > > > > ср, 19 окт. 2022 г. в 16:41, Юрий : > > > >> Slava, thank you. > >> > >> During cherry picking one of aforementioned ticket was observed > dependency > >> on > >> https://issues.apache.org/jira/browse/IGNITE-17907 > >> https://issues.apache.org/jira/browse/IGNITE-17671 > >> https://issues.apache.org/jira/browse/IGNITE-17816 > >> > >> So, I propose adding them into the release scope. > >> > >> ср, 19 окт. 2022 г. в 15:53, Вячеслав Коптилин < > slava.kopti...@gmail.com>: > >> > >>> Hi Yuriy, > >>> > >>> I agree, let's add them to the scope. > >>> > >>> Thanks, > >>> S. > >>> > >>> > >>> ср, 19 окт. 2022 г. в 15:20, Юрий : > >>> > >>>> Dear Release managers and Igniters, > >>>> > >>>> I would like to add the following tickets to Ignite 3.0.0 beta1: > >>>> > >>>> https://issues.apache.org/jira/browse/IGNITE-17820 - improvement SQL > >> and > >>>> required for the next ticket > >>>> https://issues.apache.org/jira/browse/IGNITE-17748 - related to > >> support > >>> of > >>>> indexes > >>>> https://issues.apache.org/jira/browse/IGNITE-17612 - fix issue when > >> some > >>>> queries couldn't be done. > >>>> https://issues.apache.org/jira/browse/IGNITE-17330 - support RO > >>>> transaction > >>>> by SQL > >>>> https://issues.apache.org/jira/browse/IGNITE-17859 - index filling > >>>> https://issues.apache.org/jira/browse/IGNITE-17813 - related to > >> support > >>>> indexes by SQL > >>>> https://issues.apache.org/jira/browse/IGNITE-17655 - related to > >> support > >>>> indexes by SQL > >>>> > >>>> ср, 19 окт. 2022 г. в 12:11, Вячеслав Коптилин < > >> slava.kopti...@gmail.com > >>>> : > >>>> > >>>>> Hello Alexander, > >>>>> > >>>>> Thank you for pointing this out. I fully support including RO > >>>> transactions > >>>>> into the scope of Ignite 3.0.0-beta1 release. > >>>>> > >>>>> Thanks, > >>>>> S. > >>>>> > >>>>> > >>>>> ср, 19 окт. 2022 г. в 11:42, Alexander Lapin : > >>>>> > >>>>>> Igniters, > >>>>>> > >>>>>> I would like to add following tickets to ignite-3.0.0-beta1 > >>>>>> https://issues.apache.org/jira/browse/IGNITE-17806 > >>>>>> https://issues.apache.org/jira/browse/IGNITE-17759 > >>>>>> https://issues.apache.org/jira/browse/IGNITE-17637 > >>>>>> https://issues.apache.org/jira/browse/IGNITE-17263 > >>>>>> https://issues.apache.org/jira/browse/IGNITE-17260 > >>>>>> > >>>>>> It's all about read-only transactions. > >>>>>> > >>>>>> Best regards, > >>>>>> Alexander > >>>>>> > >>>>>> пт, 14 окт. 2022 г. в 19:45, Andrey Gura : > >>>>>> > >>>>>>> Igniters, > >>>>>>> > >>>>>>> The 'ignite-3.0.0-beta1' branch was created (the latest commit is > >>>>>>> 8160ef31ecf8d49f227562b6f0ab090c6b4438c1). > >>>>>>> > >>>>>>> The scope for the release is frozen. > >>>>>>> > >>>>>>> It means the following: > >>>>>>> > >>>>>>> - Any issue could be added to the release (fixVersion == > >>> 3.0.0-beta1) > >>>>>>> only after discussion with the community and a release manager in > >>>> this > >>>>>>> thread. > >>>>>>> - Any commit to the release branch must be also applied to the > >>> 'main' > >>>>>>> branch. > >>>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Живи с улыбкой! :D > >>>> > >>> > >> > >> > >> -- > >> Живи с улыбкой! :D > >> > >
Re: [ANNOUNCE] SCOPE FREEZE for Apache Ignite 3.0.0 beta 1 RELEASE
Hi Yuriy, Let's add them. I hope that these three tasks are the last ones. Thanks, S. ср, 19 окт. 2022 г. в 16:41, Юрий : > Slava, thank you. > > During cherry picking one of aforementioned ticket was observed dependency > on > https://issues.apache.org/jira/browse/IGNITE-17907 > https://issues.apache.org/jira/browse/IGNITE-17671 > https://issues.apache.org/jira/browse/IGNITE-17816 > > So, I propose adding them into the release scope. > > ср, 19 окт. 2022 г. в 15:53, Вячеслав Коптилин : > > > Hi Yuriy, > > > > I agree, let's add them to the scope. > > > > Thanks, > > S. > > > > > > ср, 19 окт. 2022 г. в 15:20, Юрий : > > > > > Dear Release managers and Igniters, > > > > > > I would like to add the following tickets to Ignite 3.0.0 beta1: > > > > > > https://issues.apache.org/jira/browse/IGNITE-17820 - improvement SQL > and > > > required for the next ticket > > > https://issues.apache.org/jira/browse/IGNITE-17748 - related to > support > > of > > > indexes > > > https://issues.apache.org/jira/browse/IGNITE-17612 - fix issue when > some > > > queries couldn't be done. > > > https://issues.apache.org/jira/browse/IGNITE-17330 - support RO > > > transaction > > > by SQL > > > https://issues.apache.org/jira/browse/IGNITE-17859 - index filling > > > https://issues.apache.org/jira/browse/IGNITE-17813 - related to > support > > > indexes by SQL > > > https://issues.apache.org/jira/browse/IGNITE-17655 - related to > support > > > indexes by SQL > > > > > > ср, 19 окт. 2022 г. в 12:11, Вячеслав Коптилин < > slava.kopti...@gmail.com > > >: > > > > > > > Hello Alexander, > > > > > > > > Thank you for pointing this out. I fully support including RO > > > transactions > > > > into the scope of Ignite 3.0.0-beta1 release. > > > > > > > > Thanks, > > > > S. > > > > > > > > > > > > ср, 19 окт. 2022 г. в 11:42, Alexander Lapin : > > > > > > > > > Igniters, > > > > > > > > > > I would like to add following tickets to ignite-3.0.0-beta1 > > > > > https://issues.apache.org/jira/browse/IGNITE-17806 > > > > > https://issues.apache.org/jira/browse/IGNITE-17759 > > > > > https://issues.apache.org/jira/browse/IGNITE-17637 > > > > > https://issues.apache.org/jira/browse/IGNITE-17263 > > > > > https://issues.apache.org/jira/browse/IGNITE-17260 > > > > > > > > > > It's all about read-only transactions. > > > > > > > > > > Best regards, > > > > > Alexander > > > > > > > > > > пт, 14 окт. 2022 г. в 19:45, Andrey Gura : > > > > > > > > > > > Igniters, > > > > > > > > > > > > The 'ignite-3.0.0-beta1' branch was created (the latest commit is > > > > > > 8160ef31ecf8d49f227562b6f0ab090c6b4438c1). > > > > > > > > > > > > The scope for the release is frozen. > > > > > > > > > > > > It means the following: > > > > > > > > > > > > - Any issue could be added to the release (fixVersion == > > 3.0.0-beta1) > > > > > > only after discussion with the community and a release manager in > > > this > > > > > > thread. > > > > > > - Any commit to the release branch must be also applied to the > > 'main' > > > > > > branch. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Живи с улыбкой! :D > > > > > > > > -- > Живи с улыбкой! :D >
Re: [ANNOUNCE] SCOPE FREEZE for Apache Ignite 3.0.0 beta 1 RELEASE
Hi Yuriy, I agree, let's add them to the scope. Thanks, S. ср, 19 окт. 2022 г. в 15:20, Юрий : > Dear Release managers and Igniters, > > I would like to add the following tickets to Ignite 3.0.0 beta1: > > https://issues.apache.org/jira/browse/IGNITE-17820 - improvement SQL and > required for the next ticket > https://issues.apache.org/jira/browse/IGNITE-17748 - related to support of > indexes > https://issues.apache.org/jira/browse/IGNITE-17612 - fix issue when some > queries couldn't be done. > https://issues.apache.org/jira/browse/IGNITE-17330 - support RO > transaction > by SQL > https://issues.apache.org/jira/browse/IGNITE-17859 - index filling > https://issues.apache.org/jira/browse/IGNITE-17813 - related to support > indexes by SQL > https://issues.apache.org/jira/browse/IGNITE-17655 - related to support > indexes by SQL > > ср, 19 окт. 2022 г. в 12:11, Вячеслав Коптилин : > > > Hello Alexander, > > > > Thank you for pointing this out. I fully support including RO > transactions > > into the scope of Ignite 3.0.0-beta1 release. > > > > Thanks, > > S. > > > > > > ср, 19 окт. 2022 г. в 11:42, Alexander Lapin : > > > > > Igniters, > > > > > > I would like to add following tickets to ignite-3.0.0-beta1 > > > https://issues.apache.org/jira/browse/IGNITE-17806 > > > https://issues.apache.org/jira/browse/IGNITE-17759 > > > https://issues.apache.org/jira/browse/IGNITE-17637 > > > https://issues.apache.org/jira/browse/IGNITE-17263 > > > https://issues.apache.org/jira/browse/IGNITE-17260 > > > > > > It's all about read-only transactions. > > > > > > Best regards, > > > Alexander > > > > > > пт, 14 окт. 2022 г. в 19:45, Andrey Gura : > > > > > > > Igniters, > > > > > > > > The 'ignite-3.0.0-beta1' branch was created (the latest commit is > > > > 8160ef31ecf8d49f227562b6f0ab090c6b4438c1). > > > > > > > > The scope for the release is frozen. > > > > > > > > It means the following: > > > > > > > > - Any issue could be added to the release (fixVersion == 3.0.0-beta1) > > > > only after discussion with the community and a release manager in > this > > > > thread. > > > > - Any commit to the release branch must be also applied to the 'main' > > > > branch. > > > > > > > > > > > > -- > Живи с улыбкой! :D >
Re: [ANNOUNCE] SCOPE FREEZE for Apache Ignite 3.0.0 beta 1 RELEASE
Hello Alexander, Thank you for pointing this out. I fully support including RO transactions into the scope of Ignite 3.0.0-beta1 release. Thanks, S. ср, 19 окт. 2022 г. в 11:42, Alexander Lapin : > Igniters, > > I would like to add following tickets to ignite-3.0.0-beta1 > https://issues.apache.org/jira/browse/IGNITE-17806 > https://issues.apache.org/jira/browse/IGNITE-17759 > https://issues.apache.org/jira/browse/IGNITE-17637 > https://issues.apache.org/jira/browse/IGNITE-17263 > https://issues.apache.org/jira/browse/IGNITE-17260 > > It's all about read-only transactions. > > Best regards, > Alexander > > пт, 14 окт. 2022 г. в 19:45, Andrey Gura : > > > Igniters, > > > > The 'ignite-3.0.0-beta1' branch was created (the latest commit is > > 8160ef31ecf8d49f227562b6f0ab090c6b4438c1). > > > > The scope for the release is frozen. > > > > It means the following: > > > > - Any issue could be added to the release (fixVersion == 3.0.0-beta1) > > only after discussion with the community and a release manager in this > > thread. > > - Any commit to the release branch must be also applied to the 'main' > > branch. > > >
Re: [WANTED A NEW RELEASE MANAGER] Apache Ignite 3.0.0 beta 1 RELEASE
Hi Stan, > I’ll need help from a PMC to do the steps requiring PMC permissions but I can do most of the work. I'm ready to assist you with this. Thanks, Slava. чт, 13 окт. 2022 г. в 15:08, : > Hi, > > I’ll be happy to do this. > > I’ll need help from a PMC to do the steps requiring PMC permissions but I > can do most of the work. > > Any PMC who is ready to support me in this? > > Thanks, > Stan > > > On 13 Oct 2022, at 15:54, Andrey Gura wrote: > > > > Igniters, > > > > Due to personal reasons I need to take a pause so we need a new > > release manager for the Apache Ignite 3 beta 1 release. > > > > The best option is a PMC member. Committer is also a good option, but > > it will need some help from PMC members. > > > > Please feel free to submit your candidacy in this thread. >
Re: [ANNOUNCE] New PMC member: Ivan Daschinsky
Hi, Congratulations Ivan! Well-deserved! Thanks, Slava. вс, 18 сент. 2022 г. в 12:10, Zhenya Stanilovsky : > > Join the congratulations ! > > > > > >Hi Igniters! > > > >The Project Management Committee (PMC) for Apache Ignite has invited > >Ivan Daschinsky to become a member of the PMC and we are pleased to > >announce that he has accepted. > > > >Ivan contributed the Ignite Python thin client. And he is still > maintaining > >it. > >He is also actively supporting users. > > > >Please join me in congratulating Ivan on his new role. > > > >Best Regards, > >Dmitriy Pavlov > >on behalf of Apache Ignite PMC > > > >
Re: [VOTE] Ignite Packaging IEP
+1 пт, 26 авг. 2022 г. в 18:07, Mikhail Pochatkin : > Hi! No, this doesn't affect Ignite 2.x. This IEP is applicable only for > Apache Ignite 3. > > On Fri, Aug 26, 2022 at 5:47 PM Ilya Kasnacheev > > wrote: > > > Hello! > > > > Please clarify whether this is Apache Ignite 3 only and that it does not > > affect Apache Ignite 2.x (or does it?) > > > > Thanks, > > -- > > Ilya Kasnacheev > > > > > > пн, 22 авг. 2022 г. в 16:07, Mikhail Pochatkin : > > > > > Hi Igniters, > > > > > > I want to start a voting process about several points from IEP-93 [1]. > > > > > > 1. Switch Apache Ignite build system to Gradle as default. > > > 2. Consequently, after changing the build system to Gradle we need to > add > > > new third party dependencies to several Gradle plugins. This is list of > > new > > > complete time deps: > > > openapiGenerator = "org.openapi.generator:5.4.0" > > > javacc = "com.intershop.gradle.javacc:4.0.1" > > > launch4j = "edu.sc.seis.launch4j:2.5.3" > > > shadow = "com.github.johnrengelman.shadow:7.1.2" > > > cmake = "io.github.tomtzook.gradle-cmake:1.0.0" > > > jreleaser = "org.jreleaser:1.1.0" > > > 3. Agreement on all target package formats for Apache Ignite > > distributions. > > > > > > The vote is formal, see voting guidelines [3]. > > > > > > +1 - to accept all points above > > > 0 - don’t care either way > > > -1 - DO NOT accept (explain why) > > > > > > This vote will be open for at least 4 days till Friday Aug 26, 2022, > > > 22:00 Moscow TZ. > > > > > > [1] > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-93%3A+Ignite+Packaging > > > [2] https://www.apache.org/foundation/voting.html > > > > > >
Re: [ANNOUNCE] New PMC member: Taras Ledkov
Congratulations, Taras, very well deserved! Thanks, S. вс, 21 авг. 2022 г. в 19:26, Ilya Shishkov : > Congratulations, Taras! > > вс, 21 авг. 2022 г. в 09:52, Pavel Tupitsyn : > > > Congrats! > > > > Pavel > > > > On Sun, Aug 21, 2022 at 9:07 AM Ivan Pavlukhin > > wrote: > > > > > Congratulations, Taras! > > > > > > Best regards, > > > Ivan Pavlukhin > > > > > > сб, 20 авг. 2022 г. в 00:18, Dmitriy Pavlov : > > > > > > > > Hi Igniters! > > > > > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > > > Taras Ledkov to become a member of the PMC and we are pleased to > > > > announce that he has accepted. > > > > > > > > Taras is a veteran committer, and it is needless to say how long > > > > and successfully he is contributing to the Apache Ignite. > > > > Taras is responsible for a solid bulk of SQL and JDBC code. > > > > > > > > Please join me in congratulating Taras on his new role. > > > > > > > > Best Regards, > > > > Dmitriy Pavlov > > > > on behalf of Apache Ignite PMC > > > > > >
Re: [ANNOUNCE] New PMC member: Vyacheslav Koptilin
Hi Igniters, Many thanks to all of you! I really appreciate this. Thanks, S. чт, 18 авг. 2022 г. в 17:17, Andrey Mashenkov : > Congratulations, Slava! > > On Wed, Aug 17, 2022 at 5:35 PM Kseniya Romanova > wrote: > > > Hi Igniters! > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > Vyacheslav Koptilin to become a member of the PMC and we are pleased to > > announce that he has accepted. > > > > Vyacheslav is a veteran committer and contributes a lot to the Ignite > > storage https://github.com/sk0x50. > > > > Please join me in congratulating Vyacheslav on his new role. > > > > Best Regards, > > Kseniya Romanova > > on behalf of Apache Ignite PMC > > > > > -- > Best regards, > Andrey V. Mashenkov >
Re: [jira] [Created] (IGNITE-17556) Ignite doc: Wrong use of setValueFields function in CacheJdbcPojoStore demo
Hello, I will take a look. Thanks, Slava. чт, 18 авг. 2022 г. в 16:54, liyuj : > Hello, > > Is there anyone willing to help merge the following PR? > > https://github.com/apache/ignite/pull/10203 > > At 2022-08-18 21:11:00, "YuJue Li (Jira)" wrote: > >YuJue Li created IGNITE-17556: > >- > > > > Summary: Ignite doc: Wrong use of setValueFields function in > CacheJdbcPojoStore demo > > Key: IGNITE-17556 > > URL: https://issues.apache.org/jira/browse/IGNITE-17556 > > Project: Ignite > > Issue Type: Bug > > Components: documentation > >Affects Versions: 2.13 > >Reporter: YuJue Li > >Assignee: YuJue Li > > Fix For: 2.14 > > > > > >https://ignite.apache.org/docs/latest/persistence/external-storage# > > > > > > > >-- > >This message was sent by Atlassian Jira > >(v8.20.10#820010) >
Re: [ANNOUNCE] Apache Ignite 3.0.0 alpha 5: Code freeze
Hello Andrey, Data rebalancing (https://issues.apache.org/jira/browse/IGNITE-14209) is already done and merged to main & ignite-3.0.0-alpha5 branches. Thanks, S. пн, 6 июн. 2022 г. в 22:52, Andrey Gura : > Igniters, > > ignite-3.0.0-alpha5 release branch has been created. But the following > issues are still in progress: > > Data rebalancing > https://issues.apache.org/jira/browse/IGNITE-14209 > > SQL API: Add batched DML queries support. > https://issues.apache.org/jira/browse/IGNITE-16963 > > SQL API: Examples. > https://issues.apache.org/jira/browse/IGNITE-17088 > > Please, make sure these commits will be merged to the main and to the > release branch. > > Thanks! > > On Mon, Jun 6, 2022 at 6:02 PM Aleksandr Pakhomov > wrote: > > > > Hi Andrey, > > > > As for CLI MVP, the planned timeline is today till 21:00. > > Probably, will be ready in an hour. Just waiting for CI build. > > > > Best regards, > > Aleksandr > > > > > On 6 Jun 2022, at 17:56, Andrey Gura wrote: > > > > > > Igniters, > > > > > > our release schedule has shifted a bit. But it is time for a code > > > freeze and a new branch creation. > > > > > > The following issues is still in progress (not an issues status, but > > > work state): > > > > > > Data rebalancing > > > https://issues.apache.org/jira/browse/IGNITE-14209 > > > > > > CLI MVP > > > https://issues.apache.org/jira/browse/IGNITE-16971 > > > > > > [Native Persistence 3.0] End-to-end test for persistent PageMemory > > > https://issues.apache.org/jira/browse/IGNITE-17107 > > > > > > SQL API: Implement query metadata > > > https://issues.apache.org/jira/browse/IGNITE-16962 > > > > > > SQL API: Add batched DML queries support. > > > https://issues.apache.org/jira/browse/IGNITE-16963 > > > > > > SQL API: Examples. > > > https://issues.apache.org/jira/browse/IGNITE-17088 > > > > > > Please, give some planned timelines for these issues. I would like to > > > create the ignite-3.0.0-alpha5 branch today and announce Code Freeze. > > > Otherwise, extra steps will be required to include the PR's to the > > > release branch. > > > > > > Thanks! > > >
Re: [VOTE] Add micronaut dependency to Ignite 3 (reopened)
+1 Thanks, S. ср, 1 июн. 2022 г. в 12:56, Ilya Korol : > +1 > > 01.06.2022 19:14, ткаленко кирилл пишет: > > + 1 >
Re: [ANNOUNCE] Welcome Alexander Lapin as a new committer
Hi, Congratulations, Alexander! Thanks, S. ср, 9 мар. 2022 г. в 18:57, Ivan Pavlukhin : > Alex, congratulations, well deserved! > > 2022-03-09 18:18 GMT+03:00, Petr Ivanov : > > Congratulations! > > > >> On 9 Mar 2022, at 17:46, Kseniya Romanova > wrote: > >> > >> Igniters! The Apache Ignite Project Management Committee (PMC) has > >> invited > >> Alexander Lapin to become a new committer and are happy to announce that > >> he > >> has > >> accepted. > >> > >> Alexander contributed to the Ignite several important improvements of > the > >> JDBC thin driver, and tracing framework. Also, he created some valuable > >> content about Tracing and Data Rebalance. Now, he is deeply involved in > >> developing Apache Ignite 3.0. > >> > >> 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 Alexander, and congratulating him on the new > >> role in the Apache Ignite Community. > >> > >> Cheers, > >> Kseniya Romanova > > > > > > > -- > > Best regards, > Ivan Pavlukhin >
Re: Ignite 3 Join Protocol
Hello Anton, This IEP is already placed under Proposals for Ignite 3.0 section https://cwiki.apache.org/confluence/display/IGNITE/Proposals+for+Ignite+3.0 Perhaps, we need to move all that stuff to https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3 Thanks, S. пн, 21 февр. 2022 г. в 14:32, Anton Vinogradov : > Yes, but how about to have explicitly separated the IGNITE-3 project at the > confluence, where Ignite 3's IEPs will be located? > We may also call them I3EP to make clear it's about Ignite 3. > > On Mon, Feb 21, 2022 at 2:28 PM Alexander Polovtcev < > alexpolovt...@gmail.com> > wrote: > > > I've updated the title, is the current name ok? > > > > On Mon, Feb 21, 2022 at 12:29 PM Anton Vinogradov wrote: > > > > > Alexander, > > > > > > Could you please specify (at IEP's name) this IEP is related to the > > Ignite > > > 3 (only)? > > > > > > On Tue, Feb 15, 2022 at 3:28 PM Alexander Polovtcev < > > > alexpolovt...@gmail.com> > > > wrote: > > > > > > > Hello, dear Igniters! > > > > > > > > We've prepared an IEP > > > > < > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-77%3A+Node+Join+Protocol+and+Initialization > > > > > > > > > about how to assemble a cluster and add new nodes to it in Ignite 3. > > > Please > > > > note that some aspects are out of scope of this particular IEP (like > > the > > > > procedure of a node leaving a cluster). Any feedback is appreciated. > > > > > > > > -- > > > > With regards, > > > > Aleksandr Polovtcev > > > > > > > > > > > > > -- > > With regards, > > Aleksandr Polovtcev > > >
Re: Proxy (GridServiceProxy) for local services if required
Hi, > Yep, seems that current behaviour is not correct at all. `serviceProxy()` should return exactly what it should -- proxy. +1. I tend to have the same opinion. Thanks, S. ср, 19 янв. 2022 г. в 17:33, Ivan Daschinsky : > Yep, seems that current behaviour is not correct at all. `serviceProxy()` > should return exactly what it should -- proxy. > > ср, 19 янв. 2022 г. в 10:32, Maksim Timonin : > > > Hi, guys! > > > > > this is not a good idea to change the behavior of serviceProxy() > > depending on statistics > > > > I think that the patch doesn't change the behavior of `serviceProxy()`. > > This method promises a proxy and it actually returns it. The fact that > > `serviceProxy()` can return non-proxy objects is an internal Ignite > > optimization, and users should not rely on this, there is a separate > method > > `service()` for that. > > > > > What are the metrics that are being affected by this? > > > > Only service metrics, that calculates duration of service execution. > Check > > this ticket [1] > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12464 > > > > > > On Wed, Jan 19, 2022 at 1:22 AM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > What are the metrics that are being affected by this? > > > > > > -Val > > > > > > On Tue, Jan 18, 2022 at 3:31 AM Вячеслав Коптилин < > > > slava.kopti...@gmail.com> > > > wrote: > > > > > > > Hello Igniters, > > > > > > > > IMHO, this is not a good idea to change the behavior of > serviceProxy() > > > > depending on statistics (enabled/disabled). It seems counterintuitive > > to > > > > me. > > > > Perhaps, we need to introduce a new method that should always return > a > > > > proxy to the user service. > > > > > > > > Thanks, > > > > Slava. > > > > > > > > > > > > вт, 28 дек. 2021 г. в 13:57, Pavel Pereslegin : > > > > > > > > > Hi! > > > > > > > > > > Agree with Maxim. > > > > > > > > > > It seems to me quite normal to return a proxy for a local instance > in > > > > > the case when the user has explicitly enabled statistics collection > > in > > > > > the service settings. Those. by default, we do not change the > > behavior > > > > > and if the collection of metrics is not needed, a local instance > will > > > > > be returned. And I also think the javadoc should be changed to > > reflect > > > > > the new behavior. > > > > > > > > > > So, I'm for 1 + 3. > > > > > > > > > > вт, 28 дек. 2021 г. в 10:51, Maksim Timonin < > timoninma...@apache.org > > >: > > > > > > > > > > > > Hi! > > > > > > > > > > > > I agree that users shouldn't expect a non-proxy when invoking the > > > > > > `IgniteServices#serviceProxy()` method. I think it's up to Ignite > > to > > > > > return > > > > > > a non-proxy instance here as possible optimisation. But users > have > > to > > > > use > > > > > > interfaces in any case. There is the `IgniteServices#service()` > > > method > > > > > for > > > > > > explicit return of local instances. > > > > > > > > > > > > With enabling of metrics we can break users that explicitly > > > > > > use `#serviceProxy` (proxy!), and then explicitly cast it to an > > > > > > implementation class. In this case such users will get a runtime > > > > > exception. > > > > > > I think we can write a good javadoc for > > > > > > `ServiceConfiguration#setEnableMetrics()`, it should mention that > > it > > > > > works > > > > > > only with proxy, and it doesn't collect metrics with non-proxy > > usages > > > > > with > > > > > > `IgniteService#service()`. > > > > > > > > > > > > So, I propose to proceed with two solutions - 1 and 3: fix docs > for > > > > > > `#serviceProxy()` and provide detailed javadocs > > > > > > for `ServiceConfiguration#setEnableMetrics()`. > > > > > > > > > > > > If some users will enable met
Re: Proxy (GridServiceProxy) for local services if required
Hello Igniters, IMHO, this is not a good idea to change the behavior of serviceProxy() depending on statistics (enabled/disabled). It seems counterintuitive to me. Perhaps, we need to introduce a new method that should always return a proxy to the user service. Thanks, Slava. вт, 28 дек. 2021 г. в 13:57, Pavel Pereslegin : > Hi! > > Agree with Maxim. > > It seems to me quite normal to return a proxy for a local instance in > the case when the user has explicitly enabled statistics collection in > the service settings. Those. by default, we do not change the behavior > and if the collection of metrics is not needed, a local instance will > be returned. And I also think the javadoc should be changed to reflect > the new behavior. > > So, I'm for 1 + 3. > > вт, 28 дек. 2021 г. в 10:51, Maksim Timonin : > > > > Hi! > > > > I agree that users shouldn't expect a non-proxy when invoking the > > `IgniteServices#serviceProxy()` method. I think it's up to Ignite to > return > > a non-proxy instance here as possible optimisation. But users have to use > > interfaces in any case. There is the `IgniteServices#service()` method > for > > explicit return of local instances. > > > > With enabling of metrics we can break users that explicitly > > use `#serviceProxy` (proxy!), and then explicitly cast it to an > > implementation class. In this case such users will get a runtime > exception. > > I think we can write a good javadoc for > > `ServiceConfiguration#setEnableMetrics()`, it should mention that it > works > > only with proxy, and it doesn't collect metrics with non-proxy usages > with > > `IgniteService#service()`. > > > > So, I propose to proceed with two solutions - 1 and 3: fix docs for > > `#serviceProxy()` and provide detailed javadocs > > for `ServiceConfiguration#setEnableMetrics()`. > > > > If some users will enable metrics (even with such docs!) and will be > using > > casting proxy(!) to an implementation, then they will get a runtime > > exception. But I believe that it is an obvious failure, and it should be > > fixed on the user side. > > > > > > > > > > > > On Mon, Dec 27, 2021 at 10:26 PM Vladimir Steshin > > wrote: > > > > > Hi, Igniters. > > > > > > > > > I'd like to suggest modifying `/IgniteServices.serviceProxy(String > name, > > > Class svcItf, boolean sticky)/` so that it may return proxy > > > even for local service. Motivation: service metrics [1]. To measure > > > method call we need to wrap service somehow. Also, the method name says > > > `proxy`. For local one we return direct instance. Misleading. > > > > > > > > > Solutions: > > > > > > 1) Let’s return a proxy (`/GridServiceProxy/`) once we need. Let’s > > > change the javadoc to say `@return Proxy over service’. Simply works. > > > > > > Pros: invocation like `/MyServiceImpl svc = serviceProxy(«myservice», > > > MyService.class)`/ would fail. Wierd usage to me. But possible. > > > > > > 2) Introduce a new method with forced-proxy flag > > > like`IgniteSerives.serviceProxy(…, boolead focedProxy)`. And add a > > > warning to other service-obtain methods like: «`/You enabled service > > > metrics but it doesn’t work for local service instanse. Use > forced-proxy > > > serviceProxy(…, boolean forcedProxy)/` Pros: we’ve already have about > > > 5-6 methods to get services in `/IgniteServices/`. I doubt we need one > > > more. > > > > > > 3) Fix the documentation so that it tells the service metrics would > work > > > only with proxy. Pros: service metrics just won’t work for local > > > services. Suddenly. > > > > > > > > > My vote is for #1: let's use a proxy. WDYT? > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12464 > > > > > > >
Re: [ANNOUNCE] Welcome Vladislav Pyatkov as a new committer
Hi, Congratulations, Vlad! Thanks, S. чт, 23 дек. 2021 г. в 11:59, Anton Vinogradov : > Welcome aboard! > > On Thu, Dec 23, 2021 at 10:24 AM Ivan Pavlukhin > wrote: > > > Congrats, Vlad! > > > > 2021-12-22 20:48 GMT+03:00, Ivan Daschinsky : > > > Vlad, congrats! You have definitely deserved it! > > > > > > ср, 22 дек. 2021 г. в 20:40, Andrey Mashenkov < > > andrey.mashen...@gmail.com>: > > > > > >> Congrats, Vlad! > > >> > > >> ср, 22 дек. 2021 г., 20:23 Valentin Kulichenko < > > >> valentin.kuliche...@gmail.com>: > > >> > > >> > The Apache Ignite Project Management Committee (PMC) has invited > > >> Vladislav > > >> > Pyatkov to become a new committer and are happy to announce that he > > has > > >> > accepted. > > >> > > > >> > Vladislav is a veteran of the Apache Ignite project. He joined the > > >> > community in 2016. > > >> > He participated in the development of Ignite 1.x, 2.x and he is > > >> > actively > > >> > working on a new Apache Ignite 3.0 release. > > >> > > > >> > 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 Vlad, and congratulating him on the new > > >> > role > > >> > in the Apache Ignite Community. > > >> > > > >> > -Val > > >> > > > >> > > > > > > > > > -- > > > Sincerely yours, Ivan Daschinskiy > > > > > > > > > -- > > > > Best regards, > > Ivan Pavlukhin > > >
Re: [VOTE] Release Apache Ignite 2.11.1 RC2
Hello, +1 Thanks, S. пн, 20 дек. 2021 г. в 16:26, Nikolay Izhikov : > +1 (binding) > > > 20 дек. 2021 г., в 16:20, Ivan Daschinsky > написал(а): > > > > +1 from me > > Checked ODBC drivers (32-bit and 64-bit) installers on Windows with > running > > locally Ignite with > > pyodbc and python 3.9 using this script [1] > > > > > > [1] -- > https://gist.github.com/ivandasch/6cc0b56e055b826e5840b5c04fa3b2fa > > > > пн, 20 дек. 2021 г. в 15:45, Pavel Tupitsyn : > > > >> +1 > >> > >> Checked .NET binaries, nugets, and examples. > >> > >> On Mon, Dec 20, 2021 at 3:42 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com > >>> > >> wrote: > >> > >>> Hello! > >>> > >>> +1 > >>> > >>> There seems to be a correct version of log4j2 now. > >>> > >>> Btw, I've noticed that we ship log2j 1.x with ignite-rest-http. This is > >>> quite bad. > >>> > >>> Regards, > >>> -- > >>> Ilya Kasnacheev > >>> > >>> > >>> пн, 20 дек. 2021 г. в 15:35, Maxim Muzafarov : > >>> > The second release candidate for the 2.11.1 version is ready. > > Since this is an emergency release the vote will remain open for as > short an amount as time as required to vet the release. All votes are > welcome and we encourage everyone to test the release, but only PMC > votes are “officially” counted. As always, at least 3 +1 votes and > more positive than negative votes are required. See voting guidelines: > https://www.apache.org/foundation/voting.html > > +1 - to accept Apache Ignite 2.11.1-rc2 > 0 - don't care either way > -1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc2 (explain why) > > > * RELEASE CANDADATE * > > Check the release difference between 2.11 and 2.11.1: > https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1 > > I have uploaded a release candidate to: > https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc2/ > https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc2/ > > The following staging can be used for testing: > > >> > https://repository.apache.org/content/repositories/orgapacheignite-1535/ > > > >>> > >> > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > The tag name is 2.11.1-rc2: > > > >>> > >> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=eae1147dd1cd625cc229098489be8d208f6cabcc > > RELEASE_NOTES: > > > >>> > >> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1 > > Complete list of resolved issues: > > > > >>> > >> > https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.11.1%27)) > > > * CHECKS * > > Additional checks have been performed (available for users included > >> into > the release group on TeamCity). > > TC [Check RC: Licenses, compile, chksum] > > > >>> > >> > https://ci.ignite.apache.org/viewLog.html?buildId=6333527=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages > > See notes on how to verify release here > https://www.apache.org/info/verification.html > and > > > >>> > >> > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification > > >>> > >> > > > > > > -- > > Sincerely yours, Ivan Daschinskiy > >
Re: [VOTE] Release Apache Ignite 2.11.1 RC1
Hi Maxim, Ivan, Thank you for the clarification. So, I have no objections. +1 Thanks, S. пт, 17 дек. 2021 г. в 16:35, Ivan Daschinsky : > Slava, unfortunately, after some works that improves C++ bulding process, > now it is impossible to build old releases. > > пт, 17 дек. 2021 г. в 16:28, Вячеслав Коптилин : > > > Hello Maxim, > > > > Honestly, I don't quite understand why ODBC improvement is included in > the > > release. > > It seems to me, we have an agreement that the scope of the 2.11.1 release > > will be limited by log4j issues. > > > > Thanks, > > S. > > > > > > пт, 17 дек. 2021 г. в 15:20, Maxim Muzafarov : > > > > > The release candidate for the 2.11.1 version is ready. > > > > > > > > > I have uploaded a release candidate to: > > > https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc1/ > > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc1/ > > > > > > The following staging can be used for testing: > > > > https://repository.apache.org/content/repositories/orgapacheignite-1534/ > > > > > > > > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > > > > > The tag name is 2.11.1-rc1: > > > > > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.11.1-rc1 > > > > > > RELEASE_NOTES: > > > > > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1 > > > > > > > > > Complete list of resolved issues: > > > > > > Update Ignite dependency log4j > > > https://issues.apache.org/jira/browse/IGNITE-16127 > > > https://issues.apache.org/jira/browse/IGNITE-16101 > > > > > > CPP: Build ODBC installers using cmake > > > https://issues.apache.org/jira/browse/IGNITE-15678 > > > > > > ODBC: DSN can not be created by DataSource manager > > > https://issues.apache.org/jira/browse/IGNITE-15677 > > > > > > > > > Additional checks have been performed (available for users included > into > > > the release group on TeamCity). > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > > > > > > https://ci2.ignite.apache.org/viewLog.html?buildId=6235446=buildResultsDiv=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum > > > > > > > > > The vote is formal, see voting guidelines > > > https://www.apache.org/foundation/voting.html > > > > > > +1 - to accept Apache Ignite 2.11.1-rc1 > > > 0 - don't care either way > > > -1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc1 (explain why) > > > > > > See notes on how to verify release here > > > https://www.apache.org/info/verification.html > > > and > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification > > > > > > > > > This vote will be open for 3 days until Mon Dec 20, 15:00 2021 (Moscow > > > time). > > > Please, write me down the thread if you need additional time to check > > > the release. > > > > > > > > > https://www.timeanddate.com/countdown/vote?iso=20211220T15=166=%5BVOTE%5D+Apache+Ignite+2.11.1=sanserif > > > > > > > > -- > Sincerely yours, Ivan Daschinskiy >
Re: [VOTE] Release Apache Ignite 2.11.1 RC1
Hello Maxim, Honestly, I don't quite understand why ODBC improvement is included in the release. It seems to me, we have an agreement that the scope of the 2.11.1 release will be limited by log4j issues. Thanks, S. пт, 17 дек. 2021 г. в 15:20, Maxim Muzafarov : > The release candidate for the 2.11.1 version is ready. > > > I have uploaded a release candidate to: > https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc1/ > https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc1/ > > The following staging can be used for testing: > https://repository.apache.org/content/repositories/orgapacheignite-1534/ > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > The tag name is 2.11.1-rc1: > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.11.1-rc1 > > RELEASE_NOTES: > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1 > > > Complete list of resolved issues: > > Update Ignite dependency log4j > https://issues.apache.org/jira/browse/IGNITE-16127 > https://issues.apache.org/jira/browse/IGNITE-16101 > > CPP: Build ODBC installers using cmake > https://issues.apache.org/jira/browse/IGNITE-15678 > > ODBC: DSN can not be created by DataSource manager > https://issues.apache.org/jira/browse/IGNITE-15677 > > > Additional checks have been performed (available for users included into > the release group on TeamCity). > > TC [Check RC: Licenses, compile, chksum] > > https://ci2.ignite.apache.org/viewLog.html?buildId=6235446=buildResultsDiv=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum > > > The vote is formal, see voting guidelines > https://www.apache.org/foundation/voting.html > > +1 - to accept Apache Ignite 2.11.1-rc1 > 0 - don't care either way > -1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc1 (explain why) > > See notes on how to verify release here > https://www.apache.org/info/verification.html > and > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification > > > This vote will be open for 3 days until Mon Dec 20, 15:00 2021 (Moscow > time). > Please, write me down the thread if you need additional time to check > the release. > > https://www.timeanddate.com/countdown/vote?iso=20211220T15=166=%5BVOTE%5D+Apache+Ignite+2.11.1=sanserif >
Re: Apache Ignite 2.12 RELEASE [Time, Scope, Manager]
Hi Nikita, The proposed timeline looks great. Thank you! Slava. пт, 17 дек. 2021 г. в 15:32, Nikita Amelchev : > Hello, Slava. > > I am planning the following timeline: > > Voting Date: December 20, 2021 > Release Date: December 27, 2021 > > чт, 16 дек. 2021 г. в 11:52, Вячеслав Коптилин : > > > > 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, Вячеслав Коптилин < > slava.kopti...@gmail.com>: > > > > > > > > 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 < > nizhi...@apache.org > > > > > > > > > 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 < > namelc...@apache.org> > > > > > > > написал(а): > > > > > > > > > > > > > > > > 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 > > > &g
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 > > > > > > htt
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] 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 > &
Re: Apache Ignite 2.12 RELEASE [Time, Scope, Manager]
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 : > > > >> > > > >> Hello, Nikolay. > > > >> > > > >> I have cherry-picked the issue fix. > > > >> > > > >> Thank you. > > > >> > > > >> ср, 8 дек. 2021 г. в 18:47, Nikolay Izhikov : > > > >>> > > > >>> 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 > > > написал(а): > > > > > > 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 >: > > > > > > > > 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, > > > > > > is there a chance to add this issue to the release scope? [1] > > > Currently, defragmentation of certain types of indexes can > > > corrupt them. > > > Fix is straightforward and should not cause any problems. > > > Thank you! > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15968 > > > > > > вт, 23 нояб. 2021 г. в 20:44, Nikita Amelchev < > > > namelc...@apache.org>: > > > > > > > Ivan, > > > > > > > > I have cherry-picked the issue: > > > > https://issues.apache.org/jira/browse/IGNITE-15767 > > > > > > > > вт, 23 нояб. 2021 г. в 20:31, Nikolay Izhikov < > > > nizhi...@apache.org>: > > > >> > > > >>> [1] https://issues.apache.org/jira/browse/IGNITE-15951 > > > >> > > > >> Cherry-picked to 2.12 > > > >> > > > >>> 23 нояб. 2021 г., в 16:38, Nikita Amelchev < > > > namelc...@apache.org> > > > > написал(а): > > > >>> > > > >>> Hi, +1 to cherry-pick. > > > >>> > > > >>> вт, 23
Re: [DISCUSSION] Remove outdated ignite-sys-cache
Hello Maxim, The plan should be more precise. So at the very high level: > > 1. Deprecate the system cache in 2.13. > 2. Remove the system cache in 2.14. > I still think that we should not be stuck to a concrete version 2.14. The system cache should be removed when all related improvements will be done (at least, transaction support on the distributed metastorage). Thanks, S. пн, 6 дек. 2021 г. в 20:40, Maxim Muzafarov : > Val, > > The plan should be more precise. So at the very high level: > > 1. Deprecate the system cache in 2.13. > 2. Remove the system cache in 2.14. > > 2.14 should happen in the mid of the next year I suppose. > > I don't think we should write guides for the system cache > > metastorage migration process. This is a completely internal API and > we can change it. Any plugin can create its own internal cache for any > needs and if there are any hooks required for it (e.g. like > PartitionsExchangeAware interface) it might be added prior to the > removal. > > > After we agreed on this plan we can send a notification for dev, user > lists about these changes, so all the plugin developers will be up to > date. But I think that everyone has already known everything, so let's > move on :-) > > On Mon, 6 Dec 2021 at 20:22, Nikolay Izhikov wrote: > > > > Valentin, > > > > > However, changes like system cache removal are much more critical, > because a plugin might rely on it. > > > > I’m still don’t understand - what is the difference between system cache > and any other Ignite cache except the name? > > Do we have some special guarantees for system cache? > > > > > Any objections to the plan I've suggested earlier? > > > 1. Write down the differences between the system cache and the > metastorage, and provide a transition guide for plugin developers. > > > > Don’t think we need any transition guide. > > > > > I don't think it's reasonable to do this earlier than mid next year > > > > This date are questionable, also. > > > > Other points of your plan makes sense. > > +1 to follow it. > > > > > 6 дек. 2021 г., в 20:16, Valentin Kulichenko < > valentin.kuliche...@gmail.com> написал(а): > > > > > > That's correct. > > > > > > Folks, can we agree on how we want to approach the removal of the > system > > > cache? Any objections to the plan I've suggested earlier? As a > reminder, > > > here it is: > > > 1. Write down the differences between the system cache and the > metastorage, > > > and provide a transition guide for plugin developers. > > > 2. Deprecate the system cache in 2.13. > > > 3. Remove the system cache in one of the further releases. I don't > think > > > it's reasonable to do this earlier than mid next year (even that is > > > potentially too early). > > > > > > As for general compatibility requirements related to plugins, I think > they > > > obviously should not be as strict as for the public API. It's > > > understandable that a method signature can be updated, or another > similar > > > change can be made in internal APIs. However, changes like system cache > > > removal are much more critical, because a plugin might rely on it. > It's our > > > responsibility as a good friendly community to provide a reasonable > > > alternative and a reasonable timeline for such a case. > > > > > > -Val > > > > > > On Mon, Dec 6, 2021 at 8:56 AM Вячеслав Коптилин < > slava.kopti...@gmail.com> > > > wrote: > > > > > >> Hi, > > >> > > >>> Plugins have access to different internal Ignite components, such as > > >> security processor and others, and can extend the programmatic API of > > >> Ignite. > > >> > > >>> Where docs say that we, as a community, take responsibility to keep > > >> internals in the way plugin expect? > > >> Nikolay, it seems to me, that quoted text clearly states about that. > > >> Plugin has access to internal APIs and so it depends on it. If we > want to > > >> be a friendly community then we should discuss such changes > > >> (removing/changing internal APIs) and provide a reasonable time in > order to > > >> update such dependencies. > > >> > > >> I think no one in this topic is against removing sys-cache. The > question > > >> is: is it suitable for the community to deprecate using system cache > in > > >> 2.13 and removing it in 2.14 |
Re: [DISCUSSION] Remove outdated ignite-sys-cache
Hi, > Plugins have access to different internal Ignite components, such as security processor and others, and can extend the programmatic API of Ignite. > Where docs say that we, as a community, take responsibility to keep internals in the way plugin expect? Nikolay, it seems to me, that quoted text clearly states about that. Plugin has access to internal APIs and so it depends on it. If we want to be a friendly community then we should discuss such changes (removing/changing internal APIs) and provide a reasonable time in order to update such dependencies. I think no one in this topic is against removing sys-cache. The question is: is it suitable for the community to deprecate using system cache in 2.13 and removing it in 2.14 || 2.15? Am I missing something? Am I correct? Thanks, Slava. пн, 6 дек. 2021 г. в 15:00, Nikolay Izhikov : > Slava, I don’t get it. > > > Plugins have access to different internal Ignite components, such as > security processor and others, and can extend the programmatic API of > Ignite. > > Where docs say that we, as a community, take responsibility to keep > internals in the way plugin expect? > > > 6 дек. 2021 г., в 14:48, Вячеслав Коптилин > написал(а): > > > > Hello Nikolay, > > > >>> plugin framework allows to implement internal components and use the > > internal API. > >> Can you please, point out to documentation or place in Ignite code that > > describe this behaviour? > > > > Looks like it states here https://ignite.apache.org/docs/latest/plugins > > > >> The Ignite plugin system allows you to extend the core functionality of > >> Ignite. Plugins have access to different internal Ignite components, > such > >> as security processor and others, and can extend the programmatic API of > >> Ignite. > > > > > > Thanks, > > S. > > > > > > сб, 4 дек. 2021 г. в 14:54, Nikolay Izhikov : > > > >> Valentin > >> > >>> plugin framework allows to implement internal components and use the > >> internal API. > >> > >> Can you please, point out to documentation or place in Ignite code that > >> describe this behaviour? > >> AFAIK plugin can only use public API, internal API can be changed any > time > >> we want. > >> > >>> Folks, can anyone explain the rush? > >> > >> No rush from my side. > >> > >> Just want to understand your vision of integration points between Ignite > >> and plugins. > >> > >>> Is there any specific reason for it? > >> > >> Intention of IEP-80 is to improve Ignite codebase by removing abandoned > >> features. > >> > >>> But the fact is that there are users that can depend on the system > cache > >> via the plugin framework. > >> > >> Why this dependency can’t be changed to any regular cache? > >> Just replace `Ignite#cache` to `Ignite#getOrCreateCache` and that’s it. > >> > >> Do we have some special guarantees or logic besides system cache? > >> > >> > >>> 4 дек. 2021 г., в 02:14, Valentin Kulichenko < > >> valentin.kuliche...@gmail.com> написал(а): > >>> > >>> Nikolay, that's right, plugin framework allows to implement internal > >>> components and use the internal API. There is a difference between a > >> plugin > >>> and an extension that uses only public API > >>> > >>> Folks, can anyone explain the rush? Is there any specific reason for > it? > >>> > >>> I think we all agree that this is a good change - system cache has to > >> go. I > >>> guess technically it's not even a breaking change, because system cache > >> is > >>> not a public API feature. But the fact is that there are users that can > >>> depend on the system cache via the plugin framework. Let's be > respectful > >> to > >>> those users, provide a reasonable documented alternative and give time. > >>> > >>> -Val > >>> > >>> On Fri, Dec 3, 2021 at 8:18 AM Nikolay Izhikov > >> wrote: > >>> > >>>> I don’t understand how it possible. > >>>> > >>>> Are you talking about plugin that uses some kind of internal API? > >>>> > >>>>> 3 дек. 2021 г., в 18:50, Вячеслав Коптилин > > >>>> написал(а): > >>>>> > >>>>> Hello Nikolay, > >>>>> > >>>>> If I am not mistaken
Re: [DISCUSSION] Remove outdated ignite-sys-cache
Hello Nikolay, >> plugin framework allows to implement internal components and use the internal API. > Can you please, point out to documentation or place in Ignite code that describe this behaviour? Looks like it states here https://ignite.apache.org/docs/latest/plugins > The Ignite plugin system allows you to extend the core functionality of > Ignite. Plugins have access to different internal Ignite components, such > as security processor and others, and can extend the programmatic API of > Ignite. Thanks, S. сб, 4 дек. 2021 г. в 14:54, Nikolay Izhikov : > Valentin > > > plugin framework allows to implement internal components and use the > internal API. > > Can you please, point out to documentation or place in Ignite code that > describe this behaviour? > AFAIK plugin can only use public API, internal API can be changed any time > we want. > > > Folks, can anyone explain the rush? > > No rush from my side. > > Just want to understand your vision of integration points between Ignite > and plugins. > > > Is there any specific reason for it? > > Intention of IEP-80 is to improve Ignite codebase by removing abandoned > features. > > > But the fact is that there are users that can depend on the system cache > via the plugin framework. > > Why this dependency can’t be changed to any regular cache? > Just replace `Ignite#cache` to `Ignite#getOrCreateCache` and that’s it. > > Do we have some special guarantees or logic besides system cache? > > > > 4 дек. 2021 г., в 02:14, Valentin Kulichenko < > valentin.kuliche...@gmail.com> написал(а): > > > > Nikolay, that's right, plugin framework allows to implement internal > > components and use the internal API. There is a difference between a > plugin > > and an extension that uses only public API > > > > Folks, can anyone explain the rush? Is there any specific reason for it? > > > > I think we all agree that this is a good change - system cache has to > go. I > > guess technically it's not even a breaking change, because system cache > is > > not a public API feature. But the fact is that there are users that can > > depend on the system cache via the plugin framework. Let's be respectful > to > > those users, provide a reasonable documented alternative and give time. > > > > -Val > > > > On Fri, Dec 3, 2021 at 8:18 AM Nikolay Izhikov > wrote: > > > >> I don’t understand how it possible. > >> > >> Are you talking about plugin that uses some kind of internal API? > >> > >>> 3 дек. 2021 г., в 18:50, Вячеслав Коптилин > >> написал(а): > >>> > >>> Hello Nikolay, > >>> > >>> If I am not mistaken, the method you mentioned, allows to create a > "user" > >>> cache that is available through public api for the user. This does not > >>> cover the case when the plugin developer wants to hide such cache and > >>> protect it form the end user (at least, via public api). > >>> > >>> Thanks, > >>> S. > >>> > >>> пт, 3 дек. 2021 г., 14:15 Nikolay Izhikov : > >>> > >>>> Vyacheslav, Val, can you please clarify - What is the issue if > >> third-party > >>>> plugins will create «ignite-sys-cache» from the code? > >>>> > >>>> Like just replacing `Ignite#cache` with the `Ignite#getOrCreateCache`. > >>>> > >>>>> 2 дек. 2021 г., в 16:13, Вячеслав Коптилин > > >>>> написал(а): > >>>>> > >>>>> Hello Maxim, > >>>>> > >>>>>> I don't understand why you are using *backwards compatibility* for > >>>>> completely internal things. > >>>>>> Why you are thinking in terms of users usage when are talking about > >>>>> ignite-sys-cache but not thinking when refactoring > >>>>> First of all, we are talking about all plugin developers. It does not > >>>>> matter it is open-source or proprietary plugins. > >>>>> Honestly, I don't have a list of all possible plugins that have > already > >>>>> been developed and available under the ASF license, for instance. > >>>>> Do you have such a list? Can you be sure that this change will not > >> affect > >>>>> anyone? > >>>>> > >>>>>> I don't understand why you are using *backwards compatibility* for > >>>>> completely internal things. > >>&g
Re: [DISCUSSION] Remove outdated ignite-sys-cache
Hello Nikolay, If I am not mistaken, the method you mentioned, allows to create a "user" cache that is available through public api for the user. This does not cover the case when the plugin developer wants to hide such cache and protect it form the end user (at least, via public api). Thanks, S. пт, 3 дек. 2021 г., 14:15 Nikolay Izhikov : > Vyacheslav, Val, can you please clarify - What is the issue if third-party > plugins will create «ignite-sys-cache» from the code? > > Like just replacing `Ignite#cache` with the `Ignite#getOrCreateCache`. > > > 2 дек. 2021 г., в 16:13, Вячеслав Коптилин > написал(а): > > > > Hello Maxim, > > > >> I don't understand why you are using *backwards compatibility* for > > completely internal things. > >> Why you are thinking in terms of users usage when are talking about > > ignite-sys-cache but not thinking when refactoring > > First of all, we are talking about all plugin developers. It does not > > matter it is open-source or proprietary plugins. > > Honestly, I don't have a list of all possible plugins that have already > > been developed and available under the ASF license, for instance. > > Do you have such a list? Can you be sure that this change will not affect > > anyone? > > > >> I don't understand why you are using *backwards compatibility* for > > completely internal things. > >> Why you are thinking in terms of users usage when are talking about > > ignite-sys-cache but not thinking when refactoring > > The system cache was the crucial thing in the architecture of Apache > Ignite > > 1.x and 2.x (at least 2.1 - 2.11?) > > > >> All the internals have been reworked and nobody even mentioned that it > > may affect some of the plugin developers. > > Yep, perhaps, some internal parts of Apache Ignite were reworked in order > > to avoid using the system cache. > > However, it is still a part of Ignite and it works and can be used in > > plugins. > > Honestly, the mentioned alternative, I mean the distributed metastorage, > is > > the INTERNAL thing as well. > > It means that plugin developer depends on INTERNAL entities. (it does not > > matter system-cache/metastorage) > > IMHO, such questions should be CAREFULLY discussed with no rush. > > > >> I do not propose to rush with the ignite-sys-cache removal. I'd like to > > collect all the technical stuff that we depend on, fix all of them and > > after everything will be ready do a final removal. > > Good! We are on the same page! > > > >> 1. Add deprecation for the 2.12 release. I hope it is still possible. > > If I am not mistaken, the code freeze was October 29. I think it is too > > late to introduce this change. We can add deprecation for the 2.13 > release. > > > >> Apache Ignite core still have some dependencies on ignite-sys-cache that > > should fix for 2.13 > > Ok, I agree. We need to try to find out all edge cases and add new > > abilities to the metastorage in order to cover all known > > issues/requirements. > > > >> Remove the system cache in 2.14. > > It depends on our progress with improving the distributed metastorage. In > > general, I hope it will be possible. > > > > Thanks, > > S. > > > > чт, 2 дек. 2021 г. в 13:36, Maxim Muzafarov : > > > >> Pavel, > >> > >> > >> I don't understand why you are using *backwards compatibility* for > >> completely internal things. Why you are thinking in terms of users > >> usage when are talking about ignite-sys-cache but not thinking when > >> refactoring, for instance, all the checkpoint classes? Take a look at > >> the [1] issue. All the internals have been reworked and nobody even > >> mentioned that it may affect some of the plugin developers. This is > >> really strange, so I can't agree with you. > >> > >> > >> I do not propose to rush with the ignite-sys-cache removal. I'd like > >> to collect all the technical stuff that we depend on, fix all of them > >> and after everything will be ready do a final removal. Slava already > >> mentioned some crucial cases, so I hope you and Val also help with the > >> rest of them. Let's be more precise in terms *what we need to fix*. > >> > >> > >> I've made some investigations related to the ignite-sys-cache and here > >> is my proposal: > >> > >> 1. Add deprecation for the 2.12 release. I hope it is still possible. > >> > >> 2. Apache Ignite core still have some dependencies on
Re: [DISCUSSION] Remove outdated ignite-sys-cache
in GridGain, but there may be > > more, no one knows. > > Every breaking change should be carried out carefully and gradually. > > > > > > On Thu, Dec 2, 2021 at 12:34 PM Maxim Muzafarov > wrote: > > > > > Slava, > > > > > > Thank you for the comments. > > > > > > > Maxim, the community must provide a reasonable time interval in > order to > > > notify all contributors and wait for updating all 3-rd party plugins. > > > > > > This is not actually true. We must notify about changes as earlier as > > > possible and not only users but all the developers also. However, I > > > don't think that we should wait for 3-rd party plugins to be updated > > > this is an awful practice when the open-source product releases depend > > > on some of the proprietary plugins. There is no dependency between > > > Apache Ignite releases and proprietary plugin releases. If someone > > > desires to upgrade to a new version of Apache Ignite it can update its > > > plugins any time he likes. > > > > > > > We just need to provide a window that is enough to cover all related > > > issues. > > > > > > Can you share all the issues you know, please? > > > > > > > distributed meta storage does not provide the ability to atomically > > > change several properties at the same time (there are no transactions > on > > > this API). > > > > > > Can you share an example of what kind of properties we intend to > > > change at the same? Will it be enough to change them through a single > > > thread (e.g. the discovery thread or the exchange thread)? I agree > > > here that distributed metastorage should provide such an ability, > > > however, I can't find any real examples for Apache Ignite internal > > > needs. Please, share the details and let's fix it. > > > > > > On Wed, 1 Dec 2021 at 23:19, Valentin Kulichenko > > > wrote: > > > > > > > > Agree with Slava. Two months is not enough time, especially > considering > > > > that the system cache is not functionally equivalent to the > metastorage. > > > I > > > > suggest we do the following: > > > > > > > > 1. Write down the differences between the system cache and the > > > metastorage, > > > > and provide a transition guide for plugin developers. > > > > 2. Deprecate the system cache in 2.13. > > > > 3. Remove the system cache in one of the further releases. I don't > think > > > > it's reasonable to do this earlier than mid next year (even that is > > > > potentially too early). > > > > > > > > Removing the system cache is the right move, but let's be more > > > considerate > > > > to the users. There is absolutely no need to rush. > > > > > > > > -Val > > > > > > > > On Wed, Dec 1, 2021 at 7:28 AM Вячеслав Коптилин < > > > slava.kopti...@gmail.com> > > > > wrote: > > > > > > > > > Hi Maxim, > > > > > > > > > > > On the other hand, I don't see any valuable reason why the change > > > can't > > > > > be done and we should wait for the future that never comes. > > > > > Maxim, the community must provide a reasonable time interval in > order > > > to > > > > > notify all contributors and wait for updating all 3-rd party > plugins. > > > > > Honestly, it does not seem to me that two, three months (the > current > > > > > timeline - end of March is the release date, so the end of Feb is > code > > > > > freeze) are quite enough. > > > > > > > > > > > I don't see any reasons why we should keep something in the CORE > > > module > > > > > that is being used at PLUGINS only. This is a lack of architecture > > > design > > > > > that must be fixed for sure; > > > > > I agree with you. We just need to provide a window that is enough > to > > > cover > > > > > all related issues. > > > > > For example, distributed meta storage does not provide the ability > to > > > > > atomically change several properties at the same time (there are no > > > > > transactions on this API). > > > > > > > > > > Perhaps, it would be nice to plan to remove the system cache on > 2.14 or > > > >
Re: [DISCUSSION] Remove outdated ignite-sys-cache
Hi Maxim, > On the other hand, I don't see any valuable reason why the change can't be done and we should wait for the future that never comes. Maxim, the community must provide a reasonable time interval in order to notify all contributors and wait for updating all 3-rd party plugins. Honestly, it does not seem to me that two, three months (the current timeline - end of March is the release date, so the end of Feb is code freeze) are quite enough. > I don't see any reasons why we should keep something in the CORE module that is being used at PLUGINS only. This is a lack of architecture design that must be fixed for sure; I agree with you. We just need to provide a window that is enough to cover all related issues. For example, distributed meta storage does not provide the ability to atomically change several properties at the same time (there are no transactions on this API). Perhaps, it would be nice to plan to remove the system cache on 2.14 or even 2.15. What do you think? Thanks, S. вт, 30 нояб. 2021 г. в 13:58, Maxim Muzafarov : > Hello Val, > > Thank you for sharing the details. On the one hand, I agree with you > that there is no need to haste with this change and it must be > prepared carefully. On the other hand, I don't see any valuable reason > why the change can't be done and we should wait for the future that > never comes. > > Please, consider the following my considerations: > > - The release 2.13 is not started yet. It will take months to be > released (e.g. the end of March as a possible release date). The time > is more than enough; > - The 2.13 release has breaking changes, so it is a good opportunity > to fix some gaps; > - I don't see any reasons why we should keep something in the CORE > module that is being used at PLUGINS only. This is a lack of > architecture design that must be fixed for sure; > - The cache affects cluster stability and require additional human > resources for the code maintenance; > - As a straightforward solution plugins can create their own internal > caches and use them ever they like (or use the metastorage as I > mentioned earlier). Moving system cache to plugin doesn't look so > complicated and harmful; > > On Mon, 29 Nov 2021 at 23:07, Valentin Kulichenko > wrote: > > > > Maxim, > > > > You're right that the system cache is still likely to be used by plugins. > > We at GridGain use it for security features, for example. As far as I > know, > > that's not the only case. > > > > I also agree that the metastorage should be the preferred way for this > kind > > of purposes, but is there any harm in keeping the system cache for now? > > Unlike the legacy Service Grid, this is not a public feature that can be > > used directly by a regular user, so I'm not sure why the rush. > > > > How about we instead deprecate the system cache, clearly document how to > > use the metastorage as an alternative, and then complete the removal > > sometime in the future? > > > > -Val > > > > On Sun, Nov 28, 2021 at 6:49 AM Maxim Muzafarov > wrote: > > > > > Igniters, > > > > > > > > > Since the legacy service grid implementation was removed [2] I'd like > > > to remove the ignite-sys-cache also. It is still possible that some of > > > Ignite plugins (e.g. security plugin) are still using this cache, > > > however, AFAIK this is not the reason to keep the outdated system > > > cache and these plugins must be migrated to the metastorage instead. > > > > > > I've filed the issue [1] for removal. Any objections? > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-16008 > > > [2] https://issues.apache.org/jira/browse/IGNITE-15758 > > > >
Re: [ANNOUNCE] Welcome Maxim Timonin as a new committer
Hi, Congrats, Maxim! Thanks, S. вт, 30 нояб. 2021 г. в 20:13, Maksim Timonin : > Hi, guys! > > Thanks everyone :) > > On Tue, Nov 30, 2021 at 1:16 PM Petr Ivanov wrote: > > > Great news! Congratulations, Maksim! > > > > > > > On 29 Nov 2021, at 19:13, Kseniya Romanova > > wrote: > > > > > > Igniters, > > > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > Maxim > > > Timonin to become a committer and we are pleased to announce that he > has > > > accepted. > > > > > > Maxim makes valuable contributions to the Apache Ignite code, helps > > > actively to applications developers on the user list, and made a good > > start > > > in Project awareness contributing by presenting at Ignite Summit: Cloud > > > Edition. > > > > > > 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 Maxim, and congratulating him on the new > role > > > in the Apache Ignite Community! > > > > > > Kseniya Romanova > > > on behalf of Apache Ignite PMC > > > > >
Re: [ANNOUNCE] Welcome Semyon Danilov as a new committer
Hooray! Congrats! May the Force be with you! Thanks, S. ср, 1 дек. 2021 г. в 12:02, Petr Ivanov : > Congratulations! > > > > On 1 Dec 2021, at 01:48, Andrey Gura wrote: > > > > Igniters, > > > > The Apache Ignite Project Management Committee (PMC) has invited > > Semyon Danilov to become a new committer and are happy to announce > > that he > > has accepted. > > > > Semyon contributes actively to the project's code base (AI 2 & 3) and > > helps a lot with the development environment set up (you know, all > > this Maven and plugins related issues). > > > > 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 Ivan, and congratulating him on the new role > in > > the Apache Ignite Community. > > > > Best Regards, > > Andrey Gura > >
Re: Stop sending IGNITE Created e-mails to dev@
Hello, Yep, absolutely the same. Thanks, S. пт, 12 нояб. 2021 г. в 11:12, Ivan Pavlukhin : > A last one I received was IGNITE-15872 as well. > > 2021-11-11 22:43 GMT+03:00, Ilya Kasnacheev : > > Hello! > > > > For some reason, looks like it has stopped working. I did not get any > > notification for issues since IGNITE-15872. > > > > Is it just me? The settings in the JIRA seem alright. > > > > Regards, > > > > сб, 1 мая 2021 г. в 12:49, Mikhail Petrov : > > > >> It works. Thanks a lot! > >> > >> Sent from my iPhone > >> > >> On 30 Apr 2021, at 15:20, Ilya Kasnacheev > >> wrote: > >> > >> > >> Hello! > >> > >> I have added you to this role > >> > >> Regards, > >> -- > >> Ilya Kasnacheev > >> > >> > >> пт, 30 апр. 2021 г. в 11:55, Mikhail Petrov : > >> > >>> Hi, Ilya, could you please add me to "Contributors 1" role? Or can I do > >>> it myself somehow? > >>> > >>> On 29.04.2021 18:59, Ilya Kasnacheev wrote: > >>> > >>> Hello! > >>> > >>> Pavel, Yurii, I have added you both to the role. > >>> > >>> Regards, > >>> > >>> > > > > > -- > > Best regards, > Ivan Pavlukhin >
Javadoc is broken
Hello Pavel, It seems that your commit https://issues.apache.org/jira/browse/IGNITE-15801 broke the javadoc suite. Team City: https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Javadoc?branch=%3Cdefault%3E=builds#6261281 Could you please take a look? Thanks, S.
Re: [VOTE] Allow or prohibit usages of the Guava library methods
-1 I am leaning toward -1 because of vulnerability issues (that is a possible case in general). Thanks, S. ср, 8 сент. 2021 г. в 12:13, Andrey Mashenkov : > -1 > Supporting few copy-pasted methods is much easier than support dependencies > compatibility. > > On Tue, Sep 7, 2021 at 7:42 PM Zhenya Stanilovsky > wrote: > > > > > Aleksandr, thanks for this activity. > > -1 from my side, all my decisions are in linked discussion. > > > > >Dear Igniters, > > > > > >In this thread > > >< > > > https://lists.apache.org/thread.html/r4120a03a2bf32098e54e21ae02e509b0d68f413bc7cc1f8f6d85c93d%40%3Cdev.ignite.apache.org%3E > > > > > >we've been discussing the problems and opportunities of using Guava > > >< https://github.com/google/guava > in Ignite 3. We have agreed that it > > >should be added as a shaded dependency, but we haven't decided whether > to > > >allow using Guava methods in the Ignite codebase or not. Therefore I > would > > >like to propose a vote: > > > > > >[+1 Allow]: allow using Guava methods, if justified. > > >[-1 Prohibit]: prohibit using all Guava methods. > > > > > >The voting will commence on Monday, September 13th at 9:00 UTC. Also > feel > > >free to express your opinion in the original discussion thread. > > > > > >-- > > >With regards, > > >Aleksandr Polovtcev > > > > > > > > > > > > -- > Best regards, > Andrey V. Mashenkov >
Re: [ANNOUNCE] Welcome Zhenya Stanilovsky as a new committer
Hooray! Congrats! May the Force be with you! Thanks, S. пт, 30 июл. 2021 г. в 11:17, Anton Vinogradov : > Congrats! > > On Fri, Jul 30, 2021 at 10:19 AM ткаленко кирилл > wrote: > > > Zhenya, congratulations! > > > > Пересылаемое сообщение > > 30.07.2021, 09:50, "Ivan Daschinsky" : > > > > > > Zhenya, congrats, well deserved! > > > > пт, 30 июл. 2021 г. в 00:44, Andrey Mashenkov < > andrey.mashen...@gmail.com > > >: > > > > > Congratulations Zhenya! > > > > > > On Fri, Jul 30, 2021 at 12:06 AM Maxim Muzafarov > > > wrote: > > > > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > > > Zhenya Stanilovsky to become a committer and we are pleased to > > announce > > > > that > > > > he has accepted. > > > > > > > > For the last few years, Zhenya made a lot of performance fixes > > > > especially for the core modules and important contributions to the > > > > Apache Ignite codebase. He is actively involved in integrating the > > > > Calcite framework with Apache Ignite. Moreover, he has been a great > > > > help in the preparation of several Apache Ignite major releases by > > > > carrying out stress-load tests. Besides the code contributions, > Zhenya > > > > is also an active community member and help users on dev and users > > > > lists. > > > > > > > > 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 Ivan, and congratulating him on the new > > role > > > in > > > > the Apache Ignite Community. > > > > > > > > Best Regards, > > > > Maxim Muzafarov > > > > > > > > > > -- > > > Best regards, > > > Andrey V. Mashenkov > > > > Конец пересылаемого сообщения > > >
Re: Cache group re-encryption and exception handling (IGNITE-14424)
By the way, we already fixed the issue
https://issues.apache.org/jira/browse/IGNITE-14248 that looks very close to
what we are discussing now.
Thanks,
S.
чт, 15 июл. 2021 г. в 11:17, Вячеслав Коптилин :
> Hi Pavel,
>
> >As for handling the exception in this case, from my point of view, the
> impossibility of starting re-encryption is not critical for the node
> Ok, got it. Thanks for the clarification.
>
> > in this particular case, only one checked exception is possible - if
> re-encryption is started when the node is stopped
> It is always possible that an instance of RuntimeException will be thrown
> anyway, and so the caller's thread is responsible for exception handling.
> The funny edge case that I can imagine is the followng: one node cluster
> and startReencryption throws NullPointerException, for instance. It seems,
> that this exception will not trigger the FailureHandler at all.
> (Perhaps, this issue relates to exchnage future and not a problem of
> reecnryption itself).
>
> Thanks,
> S.
>
> вт, 13 июл. 2021 г. в 16:19, Pavel Pereslegin :
>
>> Hello, Slava.
>>
>> This fix is required to fix the problem described in the ticket
>> description ("Cache group re-encryption does not start after cluster
>> secondary activation").
>> As for handling the exception in this case, from my point of view, the
>> impossibility of starting re-encryption is not critical for the node
>> (these are not caching operations, detection, etc.), but perhaps I am
>> wrong here. Also, in this particular case, only one checked exception
>> is possible - if re-encryption is started when the node is stopped (I
>> think handling it with a failure handler is redundant).
>>
>> вт, 13 июл. 2021 г. в 15:49, Вячеслав Коптилин > >:
>> >
>> > Hello Pavel,
>> >
>> > Could you please assist me in understanding the fix that was
>> implemented under https://issues.apache.org/jira/browse/IGNITE-14424
>> > In particular, it seems odd to me, just logging an exception in case
>> starting re-encryption failed with an error/exception.
>> > Please take a look at
>> https://github.com/apache/ignite/pull/9036/files#diff-1c3291a1d6cee3ec3184b99547a0f49b815d64c2ba88f3471c98116c1a49bcfeR1123
>> > I think it would be nice to propagate this exception to the
>> FailureHandler (except NodeStoppingException).
>> >
>> > Perhaps, I am missing something. Is it assumed that the process of
>> re-encryption can result in an error and it is ok? And in this case, the
>> re-encryption should be triggered later by the end-user.
>> >
>> > Thanks,
>> > S.
>>
>
Re: Cache group re-encryption and exception handling (IGNITE-14424)
Hi Pavel,
>As for handling the exception in this case, from my point of view, the
impossibility of starting re-encryption is not critical for the node
Ok, got it. Thanks for the clarification.
> in this particular case, only one checked exception is possible - if
re-encryption is started when the node is stopped
It is always possible that an instance of RuntimeException will be thrown
anyway, and so the caller's thread is responsible for exception handling.
The funny edge case that I can imagine is the followng: one node cluster
and startReencryption throws NullPointerException, for instance. It seems,
that this exception will not trigger the FailureHandler at all.
(Perhaps, this issue relates to exchnage future and not a problem of
reecnryption itself).
Thanks,
S.
вт, 13 июл. 2021 г. в 16:19, Pavel Pereslegin :
> Hello, Slava.
>
> This fix is required to fix the problem described in the ticket
> description ("Cache group re-encryption does not start after cluster
> secondary activation").
> As for handling the exception in this case, from my point of view, the
> impossibility of starting re-encryption is not critical for the node
> (these are not caching operations, detection, etc.), but perhaps I am
> wrong here. Also, in this particular case, only one checked exception
> is possible - if re-encryption is started when the node is stopped (I
> think handling it with a failure handler is redundant).
>
> вт, 13 июл. 2021 г. в 15:49, Вячеслав Коптилин :
> >
> > Hello Pavel,
> >
> > Could you please assist me in understanding the fix that was implemented
> under https://issues.apache.org/jira/browse/IGNITE-14424
> > In particular, it seems odd to me, just logging an exception in case
> starting re-encryption failed with an error/exception.
> > Please take a look at
> https://github.com/apache/ignite/pull/9036/files#diff-1c3291a1d6cee3ec3184b99547a0f49b815d64c2ba88f3471c98116c1a49bcfeR1123
> > I think it would be nice to propagate this exception to the
> FailureHandler (except NodeStoppingException).
> >
> > Perhaps, I am missing something. Is it assumed that the process of
> re-encryption can result in an error and it is ok? And in this case, the
> re-encryption should be triggered later by the end-user.
> >
> > Thanks,
> > S.
>
Cache group re-encryption and exception handling (IGNITE-14424)
Hello Pavel, Could you please assist me in understanding the fix that was implemented under https://issues.apache.org/jira/browse/IGNITE-14424 In particular, it seems odd to me, just logging an exception in case starting re-encryption failed with an error/exception. Please take a look at https://github.com/apache/ignite/pull/9036/files#diff-1c3291a1d6cee3ec3184b99547a0f49b815d64c2ba88f3471c98116c1a49bcfeR1123 I think it would be nice to propagate this exception to the FailureHandler (except NodeStoppingException). Perhaps, I am missing something. Is it assumed that the process of re-encryption can result in an error and it is ok? And in this case, the re-encryption should be triggered later by the end-user. Thanks, S.
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
Hello Ivan, > At least, we could just hide params that match a specific pattern Yes, we can filter out all vm options that do not relate to Ignite, for instance. > Ilya, go ahead, file ticket and prepare a PR. Please do not rush. Let's listen to other community members. This question is about security and it should not be discussed in a hurry (even though it looks like an obvious thing). Thanks, S. чт, 1 июл. 2021 г. в 16:55, Ivan Daschinsky : > I suppose, that all normal users should not suffer from this restrictions. > Nobody will pass password using jvm options. It is absolutely insane, > normal users pass passwords using environment variables. > > At least, we could just hide params that match specific pattern > > Ilya, go ahead, file ticket and prepare a PR. > > чт, 1 июл. 2021 г., 16:45 Вячеслав Коптилин : > > > Hello, > > > > Unfortunately, the user can pass its own system properties via JVM > options > > as follows: -DMY_SECRET_PASSWORD=123 > > It does not seem, this approach is the best one. However, the user should > > have a "kostyl" in order to hide these properties and values in the log > > file, IMHO. > > > > Thanks, > > S. > > > > ср, 30 июн. 2021 г. в 22:52, Shishkov Ilya : > > > > > Hi Igniters, > > > > > > This feature [1, 2] prevents logging of the VM arguments when > > > IGNITE_TO_STRING_INCLUDE_SENSITIVE option is set to false. Till now, > > method > > > IgniteKernal#ackVmArguments remains mostly the same [3]. > > > > > > Is this behaviour actual now? Often, we should be able to get from logs > > the > > > actual VM options used at startup even if output of sensitive data is > > > restricted. > > > > > > 1. https://issues.apache.org/jira/browse/IGNITE-4991 > > > 2. > > > > > > > > > https://github.com/apache/ignite/pull/2428/commits/4f90b6fd77bd23fa818620f0757b792ba388ef93 > > > 3. > > > > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L3002 > > > > > >
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
Hello, Unfortunately, the user can pass its own system properties via JVM options as follows: -DMY_SECRET_PASSWORD=123 It does not seem, this approach is the best one. However, the user should have a "kostyl" in order to hide these properties and values in the log file, IMHO. Thanks, S. ср, 30 июн. 2021 г. в 22:52, Shishkov Ilya : > Hi Igniters, > > This feature [1, 2] prevents logging of the VM arguments when > IGNITE_TO_STRING_INCLUDE_SENSITIVE option is set to false. Till now, method > IgniteKernal#ackVmArguments remains mostly the same [3]. > > Is this behaviour actual now? Often, we should be able to get from logs the > actual VM options used at startup even if output of sensitive data is > restricted. > > 1. https://issues.apache.org/jira/browse/IGNITE-4991 > 2. > > https://github.com/apache/ignite/pull/2428/commits/4f90b6fd77bd23fa818620f0757b792ba388ef93 > 3. > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L3002 >
Re: [VOTE] Release Apache Ignite 3.0.0-alpha2 RC1
+1 Thanks, S. пн, 28 июн. 2021 г. в 18:09, Igor Sapego : > +1 > > Best Regards, > Igor > > > On Sat, Jun 26, 2021 at 1:41 AM Nikita Ivanov wrote: > > > +1 > > > > -- > > Nikita Ivanov > > > > > > > > On Fri, Jun 25, 2021 at 3:31 PM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Dear Community, > > > > > > In the last several months, the development of Ignite 3 has been moving > > > forward significantly. On top of what we already had in the first > Alpha, > > we > > > have the following features ready: > > > > > > - Replication infrastructure based on Raft > > > - In-memory atomic storage with the basic insert-read functionality > > > - New schema management engine and API > > > > > > In my view, this constitutes a significant milestone, and I propose to > > > release it as the Alpha 2. This way it will be available for download, > > and > > > anyone will be able to play with the project, run examples, get a feel > of > > > how Ignite will work in the future, and provide feedback. > > > > > > Please vote. > > > > > > --- > > > > > > The release candidate is uploaded here: > > > https://dist.apache.org/repos/dist/dev/ignite/3.0.0-alpha2-rc1/ > > > Maven staging: > > > > https://repository.apache.org/content/repositories/orgapacheignite-1522/ > > > Git tag: https://github.com/apache/ignite-3/tree/3.0.0-alpha2-rc1 > > > > > > Jira tickets: > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012315922%20AND%20fixVersion%20%3D%2012349574%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC > > > > > > DEVNOTES: > > > https://github.com/apache/ignite-3/blob/3.0.0-alpha2-rc1/DEVNOTES.md > > > > > > The vote is formal, see voting guidelines: > > > https://www.apache.org/foundation/voting.html > > > > > > +1 - accept Apache Ignite 3.0.0-alpha2 RC1 > > > 0 - don't care either way > > > -1 - DO NOT accept Apache Ignite 3.0.0-alpha2 RC1 (explain why) > > > > > > See notes on how to verify release here: > > > https://www.apache.org/info/verification.html > > > > > > This vote will be open for 72 hours and will close on June 28th at 11pm > > > UTC: > > > > > > > > > https://www.timeanddate.com/countdown/to?iso=20210628T16=224=Apache+Ignite+3.0.0-alpha2+RC1=cursive=1 > > > > > > -Val > > > > > >
Re: Stop sending IGNITE Created e-mails to dev@
Hello Ilya, Could you please add me to the "Contributors 1" role? Thanks, S. пн, 26 апр. 2021 г. в 12:29, Ilya Kasnacheev : > Hello! > > I have added you to "Contributors 1" role. Everybody in this role will > still get those "issue created" e-mail. > > Feel free in asking me to enlist. > > Regards, > -- > Ilya Kasnacheev > > > чт, 22 апр. 2021 г. в 18:16, Ivan Pavlukhin : > > > > All issues notifications are also sent to iss...@ignite.apache.org so > > one can subscribe to this list in order to track the created tickets. > > > > Does not sound as useful advice. Issues list [1] looks like real > > scrapyard, I doubt that it can be usable for anyone in current flavor. > > Can we send only "Created" notifications there? > > > > [1] https://lists.apache.org/list.html?iss...@ignite.apache.org > > > > 2021-04-21 18:30 GMT+03:00, Ilya Kasnacheev : > > > Hello! > > > > > > INFRA ticket created: > https://issues.apache.org/jira/browse/INFRA-21762 > > > > > > I have asked to keep sending the created issue notifications for > > > "Contributors 1" role, which is empty at present. So if you wish to > keep > > > getting those e-mails, please add yourself to this role or tell me to > do > > so > > > for you. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > ср, 21 апр. 2021 г. в 17:59, Alexey Goncharuk < > > alexey.goncha...@gmail.com>: > > > > > >> I support the idea. All issues notifications are also sent to > > >> iss...@ignite.apache.org so one can subscribe to this list in order > to > > >> track the created tickets. The notifications trash the devlist archive > > UI > > >> and make it extremely difficult to navigate. > > >> > > >> вт, 20 апр. 2021 г. в 18:35, Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > >: > > >> > > >> > Hello, Maxim! > > >> > > > >> > You are free to revert any commit which has led to any new stable > test > > >> > failure, or new flaky test that was non-flaky before. > > >> > > > >> > Just revert the change and reopen the ticket. > > >> > > > >> > The problem here is that it's very hard to detect on the spot, most > of > > >> > MTCGA e-mails are false positives and even if they are not, it is > not > > >> > relevant for most of developers. > > >> > > > >> > WDYT? I'm also still waiting for more input. > > >> > > > >> > Regards, > > >> > -- > > >> > Ilya Kasnacheev > > >> > > > >> > > > >> > ср, 14 апр. 2021 г. в 21:26, Maxim Muzafarov : > > >> > > > >> > > +1 for new JIRA issues > > >> > > -1 for MTCGA notifications > > >> > > > > >> > > Why we should hide errors from the dev-list? Who should take care > of > > >> > > issues reported by MTCGA.Bot in this case? > > >> > > We must apply stricter rules for such issues: a commit leading to > an > > >> > > error must be reverted. > > >> > > > > >> > > On Wed, 14 Apr 2021 at 20:00, Denis Mekhanikov > > >> > > > > >> > > wrote: > > >> > > > > > >> > > > Huge +1 to this. > > >> > > > > > >> > > > I've already brought up this topic in the past: > > >> > > > > > >> > > > > >> > > > >> > > > http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html > > >> > > > I hope some day newcomers won't need to set up their email > filters > > >> when > > >> > > > they come to the developers list. > > >> > > > > > >> > > > Denis > > >> > > > > > >> > > > ср, 14 апр. 2021 г. в 18:07, Atri Sharma : > > >> > > > > > >> > > > > +1 to move issues to the issues list. > > >> > > > > > > >> > > > > For MTCGA, maybe build@? > > >> > > > > > > >> > > > > On Wed, Apr 14, 2021 at 8:35 PM Ilya Kasnacheev > > >> > > > > > > >> > > wrote: > > >> > > > > > > > >> > > > > > Hello! > > >> > > > > > > > >> > > > > > We have a discussion on how to ensure best engagement in > dev@ > > >> > list, > > >> > > and > > >> > > > > it > > >> > > > > > seems that Issue Created emails from IGNITE project consume > a > > >> > > > > > lot > > >> > of > > >> > > > > screen > > >> > > > > > space, it's hard to spot genuine discussions in > > >> > > > > > https://lists.apache.org/list.html?dev@ignite.apache.org > for > > >> > > example. > > >> > > > > > > > >> > > > > > We already have issues@ mailing list. I propose that we > stop > > >> > > sending any > > >> > > > > > JIRA emails to dev@. If anyone wishes to get just Created > > >> emails, > > >> > > they > > >> > > > > can > > >> > > > > > subscribe to these messages in their JIRA account settings. > I > > >> > imagine > > >> > > > > most > > >> > > > > > of you already filter these messages out, so you may need to > > >> adjust > > >> > > your > > >> > > > > > filters slightly. > > >> > > > > > > > >> > > > > > A distant second is MTCGA messages, which are also > > >> > > > > > autogenerated > > >> > and > > >> > > not > > >> > > > > > informative for most readers of the channel, since they are > at > > >> best > > >> > > > > > targeted at a single committer and at worst flaky. > > >> > > > > > > > >> > > > > > Where could we move those? What is your opinion here, on > both > > >> >
Re: [DISSCUSSION] Common logger interface.
Hello Alexei, It would be nice to add something like as follows: boolean isInfoEnabled(); boolean isDebugEnabled(); or boolean isLoggable(Level) - the same way which System.Logger suggests Thanks, S. пт, 26 мар. 2021 г. в 17:41, Alexei Scherbakov : > Andrey, > > I've introduced a new class LogWrapper to fix usability issues [1] > > The suggested usage is something like: > > private static LogWrapper LOG = new LogWrapper(MyClass.class); > > [1] > > https://github.com/gridgain/apache-ignite-3/blob/9acb050a6a6a601ead849797293a1d0ad48ab9e0/modules/core/src/main/java/org/apache/ignite/lang/LogWrapper.java > > пт, 26 мар. 2021 г. в 16:05, Andrey Mashenkov >: > > > Forgot to attach a link to the PR with an example [1]. > > > > [1] https://github.com/apache/ignite-3/pull/59 > > > > On Fri, Mar 26, 2021 at 4:03 PM Andrey Mashenkov < > > andrey.mashen...@gmail.com> > > wrote: > > > > > Hi Igniters, > > > > > > In almost every new task we faced the problem of what logger has to be > > > used: JUL. log4J or any else. > > > > > > Since JDK 9 there is a System.Logger which interface looks acceptable > for > > > use, > > > excepts maybe some usability issues like method signatures. > > > LogLevel is passed as a mandatory argument, and no shortcut methods are > > > provided (like 'warn', 'error' or 'info'). > > > > > > I like Alex Scherbakov idea [1] to use a brand new JDK system logger by > > > default and > > > extend it with shortcut methods. > > > > > > I've created a ticket to unify logger usage in Ignite-3.0 project to > fix > > > already existed code. > > > > > > Any thoughts or objections? > > > > > > -- > > > Best regards, > > > Andrey V. Mashenkov > > > > > > > > > -- > > Best regards, > > Andrey V. Mashenkov > > > > > -- > > Best regards, > Alexei Scherbakov >
Re: IEP-70: Async Continuation Executor
Hi Pavel,
> Not a good excuse really. We have a usability problem, you have to admit
it.
Fair enough. I agree that this is a usability issue, but I have doubts that
the proposed approach to overcome it is the best one.
> Documentation won't help - no one is going to read the Javadoc for a
trivial method like putAsync
That is sad... However, I don't think that this is a strong argument here.
This is just my opinion. Let's see what other community members have to say.
Thanks,
S.
ср, 17 мар. 2021 г. в 17:01, Pavel Tupitsyn :
> > the user should use the right API
>
> Not a good excuse really. We have a usability problem, you have to admit
> it.
> "The brakes did not work on your car - too bad, you should have known that
> on Sundays only your left foot is allowed on the pedal"
>
> This particular use case is too intricate.
> Even when you know about that, it is difficult to decide what can run on
> the striped pool,
> and what can't. It is too easy to forget.
> And most people don't know, even among Ignite developers.
>
> Documentation won't help - no one is going to read the Javadoc for a
> trivial method like putAsync.
>
>
> So I propose to have a safe default.
> Then document the performance tuning opportunity on [1].
>
> Think about how many users abandon a product because it mysteriously
> crashes and hangs.
>
> [1]
>
> https://ignite.apache.org/docs/latest/perf-and-troubleshooting/general-perf-tips
>
>
> On Wed, Mar 17, 2021 at 4:21 PM Вячеслав Коптилин <
> slava.kopti...@gmail.com>
> wrote:
>
> > Hi Pavel,
> >
> > Well, I think that the user should use the right API instead of
> introducing
> > uncontested overhead for everyone.
> > For instance, the code that is provided by IEP can changed as follows:
> >
> > IgniteFuture fut = cache.putAsync(1, 1);
> > fut.listenAync(f -> {
> > // Executes on Striped pool and deadlocks.
> > cache.replace(1, 2);
> > }, ForkJoinPool.commonPool());
> >
> > Of course, it does not mean that this fact should not be properly
> > documented.
> > Perhaps, I am missing something.
> >
> > Thanks,
> > S.
> >
> > ср, 17 мар. 2021 г. в 16:01, Pavel Tupitsyn :
> >
> > > Slava,
> > >
> > > Your suggestion is to keep things as is and discard the IEP, right?
> > >
> > > > this can lead to significant overhead
> > > Yes, there is some overhead, but the cost of accidentally starving the
> > > striped pool is worse,
> > > not to mention the deadlocks.
> > >
> > > I believe that we should favor correctness over performance in any
> case.
> > >
> > >
> > > On Wed, Mar 17, 2021 at 3:34 PM Вячеслав Коптилин <
> > > slava.kopti...@gmail.com>
> > > wrote:
> > >
> > > > Well, the specified method already exists :)
> > > >
> > > > /**
> > > > * Registers listener closure to be asynchronously notified
> > whenever
> > > > future completes.
> > > > * Closure will be processed in specified executor.
> > > > *
> > > > * @param lsnr Listener closure to register. Cannot be {@code
> > null}.
> > > > * @param exec Executor to run listener. Cannot be {@code null}.
> > > > */
> > > > public void listenAsync(IgniteInClosure>
> > > lsnr,
> > > > Executor exec);
> > > >
> > > > Thanks,
> > > > S.
> > > >
> > > > ср, 17 мар. 2021 г. в 15:25, Вячеслав Коптилин <
> > slava.kopti...@gmail.com
> > > >:
> > > >
> > > > > Hello Pavel,
> > > > >
> > > > > I took a look at your IEP and pool request. I have the following
> > > > concerns.
> > > > > First of all, this change breaks the contract of
> > > > IgniteFuture#listen(lsnr)
> > > > >
> > > > > /**
> > > > > * Registers listener closure to be asynchronously notified
> > > whenever
> > > > > future completes.
> > > > > * Closure will be processed in thread that completes this
> future
> > > or
> > > > > (if future already
> > > > > * completed) immediately in current thread.
> > > > > *
> > > > > * @param lsnr Listener closure to register. Cannot be {@code
> > > null}.
> > > > > */
> > > > > public void listen(IgniteInClosure>
> &
Re: IEP-70: Async Continuation Executor
Hi Pavel,
Well, I think that the user should use the right API instead of introducing
uncontested overhead for everyone.
For instance, the code that is provided by IEP can changed as follows:
IgniteFuture fut = cache.putAsync(1, 1);
fut.listenAync(f -> {
// Executes on Striped pool and deadlocks.
cache.replace(1, 2);
}, ForkJoinPool.commonPool());
Of course, it does not mean that this fact should not be properly
documented.
Perhaps, I am missing something.
Thanks,
S.
ср, 17 мар. 2021 г. в 16:01, Pavel Tupitsyn :
> Slava,
>
> Your suggestion is to keep things as is and discard the IEP, right?
>
> > this can lead to significant overhead
> Yes, there is some overhead, but the cost of accidentally starving the
> striped pool is worse,
> not to mention the deadlocks.
>
> I believe that we should favor correctness over performance in any case.
>
>
> On Wed, Mar 17, 2021 at 3:34 PM Вячеслав Коптилин <
> slava.kopti...@gmail.com>
> wrote:
>
> > Well, the specified method already exists :)
> >
> > /**
> > * Registers listener closure to be asynchronously notified whenever
> > future completes.
> > * Closure will be processed in specified executor.
> > *
> > * @param lsnr Listener closure to register. Cannot be {@code null}.
> > * @param exec Executor to run listener. Cannot be {@code null}.
> > */
> > public void listenAsync(IgniteInClosure>
> lsnr,
> > Executor exec);
> >
> > Thanks,
> > S.
> >
> > ср, 17 мар. 2021 г. в 15:25, Вячеслав Коптилин >:
> >
> > > Hello Pavel,
> > >
> > > I took a look at your IEP and pool request. I have the following
> > concerns.
> > > First of all, this change breaks the contract of
> > IgniteFuture#listen(lsnr)
> > >
> > > /**
> > > * Registers listener closure to be asynchronously notified
> whenever
> > > future completes.
> > > * Closure will be processed in thread that completes this future
> or
> > > (if future already
> > > * completed) immediately in current thread.
> > > *
> > > * @param lsnr Listener closure to register. Cannot be {@code
> null}.
> > > */
> > > public void listen(IgniteInClosure> lsnr);
> > >
> > > In your pull request, the listener is always called from a
> specified
> > > thread pool (which is fork-join by default)
> > > even though the future is already completed at the moment the
> listen
> > > method is called.
> > > In my opinion, this can lead to significant overhead - submission
> > > requires acquiring a lock and notifying a pool thread.
> > >
> > > It seems to me, that we should not change the current behavior.
> > > However, thread pool executor can be added as an optional parameter of
> > > listen() method as follows:
> > >
> > > public void listen(IgniteInClosure>
> lsnr,
> > > Executor exec);
> > >
> > > Thanks,
> > > S.
> > >
> > > пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn :
> > >
> > >> Igniters,
> > >>
> > >> Please review the IEP [1] and let me know your thoughts.
> > >>
> > >> [1]
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor
> > >>
> > >
> >
>
Re: IEP-70: Async Continuation Executor
Well, the specified method already exists :)
/**
* Registers listener closure to be asynchronously notified whenever
future completes.
* Closure will be processed in specified executor.
*
* @param lsnr Listener closure to register. Cannot be {@code null}.
* @param exec Executor to run listener. Cannot be {@code null}.
*/
public void listenAsync(IgniteInClosure> lsnr,
Executor exec);
Thanks,
S.
ср, 17 мар. 2021 г. в 15:25, Вячеслав Коптилин :
> Hello Pavel,
>
> I took a look at your IEP and pool request. I have the following concerns.
> First of all, this change breaks the contract of IgniteFuture#listen(lsnr)
>
> /**
> * Registers listener closure to be asynchronously notified whenever
> future completes.
> * Closure will be processed in thread that completes this future or
> (if future already
> * completed) immediately in current thread.
> *
> * @param lsnr Listener closure to register. Cannot be {@code null}.
> */
> public void listen(IgniteInClosure> lsnr);
>
> In your pull request, the listener is always called from a specified
> thread pool (which is fork-join by default)
> even though the future is already completed at the moment the listen
> method is called.
> In my opinion, this can lead to significant overhead - submission
> requires acquiring a lock and notifying a pool thread.
>
> It seems to me, that we should not change the current behavior.
> However, thread pool executor can be added as an optional parameter of
> listen() method as follows:
>
> public void listen(IgniteInClosure> lsnr,
> Executor exec);
>
> Thanks,
> S.
>
> пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn :
>
>> Igniters,
>>
>> Please review the IEP [1] and let me know your thoughts.
>>
>> [1]
>>
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor
>>
>
Re: IEP-70: Async Continuation Executor
Hello Pavel,
I took a look at your IEP and pool request. I have the following concerns.
First of all, this change breaks the contract of IgniteFuture#listen(lsnr)
/**
* Registers listener closure to be asynchronously notified whenever
future completes.
* Closure will be processed in thread that completes this future or
(if future already
* completed) immediately in current thread.
*
* @param lsnr Listener closure to register. Cannot be {@code null}.
*/
public void listen(IgniteInClosure> lsnr);
In your pull request, the listener is always called from a specified
thread pool (which is fork-join by default)
even though the future is already completed at the moment the listen
method is called.
In my opinion, this can lead to significant overhead - submission
requires acquiring a lock and notifying a pool thread.
It seems to me, that we should not change the current behavior.
However, thread pool executor can be added as an optional parameter of
listen() method as follows:
public void listen(IgniteInClosure> lsnr,
Executor exec);
Thanks,
S.
пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn :
> Igniters,
>
> Please review the IEP [1] and let me know your thoughts.
>
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor
>
Re: [ANNOUNCE] Welcome Ivan Bessonov as a new committer
Hello, My congratulations, Ivan! May the Force be with you! Thanks, S. вт, 12 янв. 2021 г. в 14:27, Ivan Pavlukhin : > Ivan, congratulations! > > 2021-01-12 13:36 GMT+03:00, Kseniya Romanova : > > Ivan, my congratulations! > > > > вт, 12 янв. 2021 г. в 13:32, Andrey Gura : > > > >> Igniters, > >> > >> The Apache Ignite Project Management Committee (PMC) has invited Ivan > >> Bessonov to become a new committer and are happy to announce that he > >> has accepted. > >> > >> Ivan has a lot of contributions to the Apache Ignite project. He > >> implemented Distributed Meta Storage feature which is one of key > >> features in the project. Also he contributed non trivial > >> improvements to such important parts of the project as Communication, > >> Discovery, Page Memory and Native Persistence. Another simple, but > >> very useful contribution is the widely used @WithSystemProperty > >> annotation for Apache Ignite test framework > >> > >> 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 Ivan, and congratulating him on the new role > >> in > >> the Apache Ignite Community. > >> > >> Best Regards, > >> Andrey Gura > >> > > > > > -- > > Best regards, > Ivan Pavlukhin >
Re: [RESULT] [VOTE] Removing MVCC public API
Hello Maxim, I don't see any reason for rushing. I think, that deprecating this API would be enough for 2.10. Thanks, S. чт, 17 дек. 2020 г. в 12:58, Maxim Muzafarov : > Hello Slava, > > Should we consider to include the MVCC public API removal to the 2.10 > release? > > [1] https://issues.apache.org/jira/browse/IGNITE-13871 > > On Thu, 17 Dec 2020 at 12:23, Вячеслав Коптилин > wrote: > > > > The vote is closed now. > > > > Vote result: Vote passed with 13 "+1" votes, no "0" and no "-1" votes. > > > > +1 Votes: > > Valentin Kulichenko > > Nikolay Izhikov > > Andrey Gura > > Igor Seliverstov > > Andrey Mashenkov > > Kirill Tkalenko > > Nikita Amelchev > > Petr Ivanov > > Alexei Scherbakov > > Maxim Muzafarov > > Yuriy Gerzhedowich > > Konstantin Orlov > > Alexander Lapin > > > > Vote thread: > > > http://apache-ignite-developers.2346864.n4.nabble.com/Removing-MVCC-public-API-tp50550.html > > Jira: https://issues.apache.org/jira/browse/IGNITE-13871 > > > > Thanks, > > S. >
[RESULT] [VOTE] Removing MVCC public API
The vote is closed now. Vote result: Vote passed with 13 "+1" votes, no "0" and no "-1" votes. +1 Votes: Valentin Kulichenko Nikolay Izhikov Andrey Gura Igor Seliverstov Andrey Mashenkov Kirill Tkalenko Nikita Amelchev Petr Ivanov Alexei Scherbakov Maxim Muzafarov Yuriy Gerzhedowich Konstantin Orlov Alexander Lapin Vote thread: http://apache-ignite-developers.2346864.n4.nabble.com/Removing-MVCC-public-API-tp50550.html Jira: https://issues.apache.org/jira/browse/IGNITE-13871 Thanks, S.
Re: Disable MVCC test suites
> Can you start the vote? Yes, it can be done. However, I don't think that we will get an agreement on that (I just recall the previous discussion). And so, we will not remove the MVCC code; on the other hand, nobody will support it in the future. We already at this point. This is just my humble opinion. > It's strange turning off here the whole MVCC tests just because something in the master branch was broken when in the second thread On one side, it looks weird, I agree. On the other hand, nobody cares about that and wants to fix tests. This is a stalemate, I think. Thanks, S. ср, 2 дек. 2020 г. в 16:47, Maxim Muzafarov : > Slava, > > Can you start the vote? > > It's strange turning off here the whole MVCC tests just because > something in the master branch was broken when in the second thread > Community decide to continue MVCC support. Let's start the vote and > see what happens. > > On Wed, 2 Dec 2020 at 16:39, Вячеслав Коптилин > wrote: > > > > > It will be even worse if our users will face NPE or things like that > in > > the basic MVCC scenarios just because we don’t tests it. > > The feature is not production-ready, and I don't think it is used at all. > > Moreover, MVCC Cache 7, 8, 8, MVCC PDS 1, 2, 4 are already broken > > (execution timeouts, flaky test, etc) and I haven't seen anyone who would > > like to fix this. > > Why should we waste every contributor's time? IMHO, MVCC suites are > useless > > and everyone just pushes "re-run possible blockers" button and doesn't > care > > about MVCC tests at all. > > > > Thanks, > > S. > > > > ср, 2 дек. 2020 г. в 16:01, Nikolay Izhikov : > > > > > > I think test suites can be disabled even today > > > > > > I’m -1 to disable tests without complete removal. > > > It will be even worse if our users will face NPE or things like that in > > > the basic MVCC scenarios just because we don’t tests it. > > > > > > > > > > 2 дек. 2020 г., в 15:50, Вячеслав Коптилин > > > > написал(а): > > > > > > > > Hi Nikolay, > > > > > > > >> Why do we need feature in the project that not even tested > regularly? > > > > Fair enough. However, I am not an expert in this area (MVCC and > SQL), so > > > I > > > > cannot say how much effort it will take. > > > > I would say that the opinion of the rest of the community is needed > here. > > > > > > > > Anyway, I think test suites can be disabled even today, while the > fate of > > > > the MVCC feature can be (and should be) discussed separately. > > > > What do you think? > > > > > > > > Thanks, > > > > S. > > > > > > > > ср, 2 дек. 2020 г. в 15:38, Nikolay Izhikov : > > > > > > > >> Hello, Slava! > > > >> > > > >> Yes, this topic comes to the top from time to time :) > > > >> > > > >>> . I just want to save the time required for getting TCBot's visa > and TC > > > >> resources. > > > >> > > > >> Why do we need feature in the project that not even tested > regularly? > > > >> > > > >>> 2 дек. 2020 г., в 15:36, Вячеслав Коптилин < > slava.kopti...@gmail.com> > > > >> написал(а): > > > >>> > > > >>> Hello Nikolay, > > > >>> > > > >>>> +1 to vote for complete MVCC removal. > > > >>> It has already been discussed here [1] and, unfortunately, I have > not > > > >> seen > > > >>> an agreement on that. > > > >>> > > > >>> [1] > > > >>> > > > >> > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html > > > >>> > > > >>> > > > >>> Thanks, > > > >>> S. > > > >>> > > > >>> ср, 2 дек. 2020 г. в 13:05, Nikolay Izhikov : > > > >>> > > > >>>> +1 to vote for complete MVCC removal. > > > >>>> > > > >>>> MVCC is a great feature but we should implement it as a > first-class > > > >>>> feature and not «something that pretends to be working» > > > >>>> > > > >>>>> 2 дек. 2020 г., в 12:53, Maxim Muzafarov > > > >> написал(а): > > > >>>>> > > > >>>>> Hello Slava, > > > >>>>> > > > >>>>> I think we should vote for MVCC termination of support. If the > vote > > > >>>>> will be successful than remove it from the source code and > disable > > > >>>>> MVCC suites. > > > >>>>> > > > >>>>> Only disabling tests from MVCC sounds not good. > > > >>>>> > > > >>>>> On Wed, 2 Dec 2020 at 12:32, Вячеслав Коптилин < > > > >> slava.kopti...@gmail.com> > > > >>>> wrote: > > > >>>>>> > > > >>>>>> Hello Igniters, > > > >>>>>> > > > >>>>>> It looks like there is no activity related to maintaining or > > > >> developing > > > >>>> the > > > >>>>>> MVCC feature. > > > >>>>>> So, I see no reason to waste TeamCity resources. I propose to > > > disable > > > >>>> the > > > >>>>>> corresponding test suites. > > > >>>>>> This has already been discussed here as well [1]. > > > >>>>>> > > > >>>>>> [1] > > > >>>>>> > > > >>>> > > > >> > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html > > > >>>>>> > > > >>>>>> Thanks, > > > >>>>>> S. > > > >>>> > > > >>>> > > > >> > > > >> > > > > > > >
Re: Disable MVCC test suites
> It will be even worse if our users will face NPE or things like that in the basic MVCC scenarios just because we don’t tests it. The feature is not production-ready, and I don't think it is used at all. Moreover, MVCC Cache 7, 8, 8, MVCC PDS 1, 2, 4 are already broken (execution timeouts, flaky test, etc) and I haven't seen anyone who would like to fix this. Why should we waste every contributor's time? IMHO, MVCC suites are useless and everyone just pushes "re-run possible blockers" button and doesn't care about MVCC tests at all. Thanks, S. ср, 2 дек. 2020 г. в 16:01, Nikolay Izhikov : > > I think test suites can be disabled even today > > I’m -1 to disable tests without complete removal. > It will be even worse if our users will face NPE or things like that in > the basic MVCC scenarios just because we don’t tests it. > > > > 2 дек. 2020 г., в 15:50, Вячеслав Коптилин > написал(а): > > > > Hi Nikolay, > > > >> Why do we need feature in the project that not even tested regularly? > > Fair enough. However, I am not an expert in this area (MVCC and SQL), so > I > > cannot say how much effort it will take. > > I would say that the opinion of the rest of the community is needed here. > > > > Anyway, I think test suites can be disabled even today, while the fate of > > the MVCC feature can be (and should be) discussed separately. > > What do you think? > > > > Thanks, > > S. > > > > ср, 2 дек. 2020 г. в 15:38, Nikolay Izhikov : > > > >> Hello, Slava! > >> > >> Yes, this topic comes to the top from time to time :) > >> > >>> . I just want to save the time required for getting TCBot's visa and TC > >> resources. > >> > >> Why do we need feature in the project that not even tested regularly? > >> > >>> 2 дек. 2020 г., в 15:36, Вячеслав Коптилин > >> написал(а): > >>> > >>> Hello Nikolay, > >>> > >>>> +1 to vote for complete MVCC removal. > >>> It has already been discussed here [1] and, unfortunately, I have not > >> seen > >>> an agreement on that. > >>> > >>> [1] > >>> > >> > http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html > >>> > >>> > >>> Thanks, > >>> S. > >>> > >>> ср, 2 дек. 2020 г. в 13:05, Nikolay Izhikov : > >>> > >>>> +1 to vote for complete MVCC removal. > >>>> > >>>> MVCC is a great feature but we should implement it as a first-class > >>>> feature and not «something that pretends to be working» > >>>> > >>>>> 2 дек. 2020 г., в 12:53, Maxim Muzafarov > >> написал(а): > >>>>> > >>>>> Hello Slava, > >>>>> > >>>>> I think we should vote for MVCC termination of support. If the vote > >>>>> will be successful than remove it from the source code and disable > >>>>> MVCC suites. > >>>>> > >>>>> Only disabling tests from MVCC sounds not good. > >>>>> > >>>>> On Wed, 2 Dec 2020 at 12:32, Вячеслав Коптилин < > >> slava.kopti...@gmail.com> > >>>> wrote: > >>>>>> > >>>>>> Hello Igniters, > >>>>>> > >>>>>> It looks like there is no activity related to maintaining or > >> developing > >>>> the > >>>>>> MVCC feature. > >>>>>> So, I see no reason to waste TeamCity resources. I propose to > disable > >>>> the > >>>>>> corresponding test suites. > >>>>>> This has already been discussed here as well [1]. > >>>>>> > >>>>>> [1] > >>>>>> > >>>> > >> > http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html > >>>>>> > >>>>>> Thanks, > >>>>>> S. > >>>> > >>>> > >> > >> > >
Re: Disable MVCC test suites
Hi Nikolay, > Why do we need feature in the project that not even tested regularly? Fair enough. However, I am not an expert in this area (MVCC and SQL), so I cannot say how much effort it will take. I would say that the opinion of the rest of the community is needed here. Anyway, I think test suites can be disabled even today, while the fate of the MVCC feature can be (and should be) discussed separately. What do you think? Thanks, S. ср, 2 дек. 2020 г. в 15:38, Nikolay Izhikov : > Hello, Slava! > > Yes, this topic comes to the top from time to time :) > > > . I just want to save the time required for getting TCBot's visa and TC > resources. > > Why do we need feature in the project that not even tested regularly? > > > 2 дек. 2020 г., в 15:36, Вячеслав Коптилин > написал(а): > > > > Hello Nikolay, > > > >> +1 to vote for complete MVCC removal. > > It has already been discussed here [1] and, unfortunately, I have not > seen > > an agreement on that. > > > > [1] > > > http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html > > > > > > Thanks, > > S. > > > > ср, 2 дек. 2020 г. в 13:05, Nikolay Izhikov : > > > >> +1 to vote for complete MVCC removal. > >> > >> MVCC is a great feature but we should implement it as a first-class > >> feature and not «something that pretends to be working» > >> > >>> 2 дек. 2020 г., в 12:53, Maxim Muzafarov > написал(а): > >>> > >>> Hello Slava, > >>> > >>> I think we should vote for MVCC termination of support. If the vote > >>> will be successful than remove it from the source code and disable > >>> MVCC suites. > >>> > >>> Only disabling tests from MVCC sounds not good. > >>> > >>> On Wed, 2 Dec 2020 at 12:32, Вячеслав Коптилин < > slava.kopti...@gmail.com> > >> wrote: > >>>> > >>>> Hello Igniters, > >>>> > >>>> It looks like there is no activity related to maintaining or > developing > >> the > >>>> MVCC feature. > >>>> So, I see no reason to waste TeamCity resources. I propose to disable > >> the > >>>> corresponding test suites. > >>>> This has already been discussed here as well [1]. > >>>> > >>>> [1] > >>>> > >> > http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html > >>>> > >>>> Thanks, > >>>> S. > >> > >> > >
Re: Disable MVCC test suites
Hello Nikolay, > +1 to vote for complete MVCC removal. It has already been discussed here [1] and, unfortunately, I have not seen an agreement on that. [1] http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html Thanks, S. ср, 2 дек. 2020 г. в 13:05, Nikolay Izhikov : > +1 to vote for complete MVCC removal. > > MVCC is a great feature but we should implement it as a first-class > feature and not «something that pretends to be working» > > > 2 дек. 2020 г., в 12:53, Maxim Muzafarov написал(а): > > > > Hello Slava, > > > > I think we should vote for MVCC termination of support. If the vote > > will be successful than remove it from the source code and disable > > MVCC suites. > > > > Only disabling tests from MVCC sounds not good. > > > > On Wed, 2 Dec 2020 at 12:32, Вячеслав Коптилин > wrote: > >> > >> Hello Igniters, > >> > >> It looks like there is no activity related to maintaining or developing > the > >> MVCC feature. > >> So, I see no reason to waste TeamCity resources. I propose to disable > the > >> corresponding test suites. > >> This has already been discussed here as well [1]. > >> > >> [1] > >> > http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html > >> > >> Thanks, > >> S. > >
Re: Disable MVCC test suites
Hello Maxim, > I think we should vote for MVCC termination of support. Honestly, my goal is simple and not so ambitious. I just want to save the time required for getting TCBot's visa and TC resources. Thanks, S. ср, 2 дек. 2020 г. в 12:54, Maxim Muzafarov : > Hello Slava, > > I think we should vote for MVCC termination of support. If the vote > will be successful than remove it from the source code and disable > MVCC suites. > > Only disabling tests from MVCC sounds not good. > > On Wed, 2 Dec 2020 at 12:32, Вячеслав Коптилин > wrote: > > > > Hello Igniters, > > > > It looks like there is no activity related to maintaining or developing > the > > MVCC feature. > > So, I see no reason to waste TeamCity resources. I propose to disable the > > corresponding test suites. > > This has already been discussed here as well [1]. > > > > [1] > > > http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html > > > > Thanks, > > S. >
Disable MVCC test suites
Hello Igniters, It looks like there is no activity related to maintaining or developing the MVCC feature. So, I see no reason to waste TeamCity resources. I propose to disable the corresponding test suites. This has already been discussed here as well [1]. [1] http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html Thanks, S.
Re: Alex Plehanov joins Ignite Project Management Committee
Hooray! Congratulations, Alex! Well deserved achievement! Thanks, S. ср, 18 нояб. 2020 г. в 03:26, Denis Magda : > Igniters, > > The Project Management Committee (PMC) for Apache Ignite > has invited Alex to become a PMC member and we are pleased to announce that > he has accepted. > > Alex joined our community back in 2018 and became one of the key community > members. > He made numerous contributions > < > https://issues.apache.org/jira/browse/IGNITE-13595?jql=project%20%3D%20Ignite%20and%20assignee%20%3D%20alex_pl%20and%20status%20in%20(Closed%2C%20Resolved) > > > since > then, was driving Ignite 2.9 as a release manager, regularly participates > in the dev lists discussions pertaining to the future and evolution of > Ignite. > > Join me in congratulating Alex! > > > - > Denis >
Re: [DISCUSSION] Cache warmup
Hello Kirill,
Thanks a lot for driving this activity. If I am not mistaken, this
discussion relates to IEP-40.
> I suggest adding a warmup phase after recovery here [1] after [2], before
discovery.
This means that the user's thread, which starts Ignite via
Ignition.start(), will wait for ana additional step - cache warm-up.
I think this fact has to be clearly mentioned in our documentation (at
Javadocat least) because this step can be time-consuming.
> I suggest adding a new interface:
I would change it a bit. First of all, it would be nice to place this
interface to a public package and get rid of using GridCacheContext,
which is an internal class and it should not leak to the public API in any
case.
Perhaps, this parameter is not needed at all or we should add some public
abstraction instead of internal class.
package org.apache.ignite.configuration;
import org.apache.ignite.IgniteCheckedException;
import org.apache.ignite.lang.IgniteFuture;
public interface CacheWarmupper {
/**
* Warmup cache.
*
* @param cachename Cache name.
* @return Future cache warmup.
* @throws IgniteCheckedException If failed.
*/
IgniteFuture warmup(String cachename) throws IgniteCheckedException;
}
Thanks,
S.
пн, 27 июл. 2020 г. в 15:03, ткаленко кирилл :
> Now, after restarting node, we have only cold caches, which at first
> requests to them will gradually load data from disks, which can slow down
> first calls to them.
> If node has more RAM than data on disk, then they can be loaded at start
> "warmup", thereby solving the issue of slowdowns during first calls to
> caches.
>
> I suggest adding a warmup phase after recovery here [1] after [2], before
> descovery.
>
> I suggest adding a new interface:
>
> package org.apache.ignite.internal.processors.cache;
>
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.internal.IgniteInternalFuture;
> import org.jetbrains.annotations.Nullable;
>
> /**
> * Interface for warming up cache.
> */
> public interface CacheWarmup {
> /**
> * Warmup cache.
> *
> * @param cacheCtx Cache context.
> * @return Future cache warmup.
> * @throws IgniteCheckedException if failed.
> */
> @Nullable IgniteInternalFuture process(GridCacheContext cacheCtx)
> throws IgniteCheckedException;
> }
>
> Which will allow to warm up caches in parallel and asynchronously. Warmup
> phase will end after all IgniteInternalFuture for all caches isDone.
>
> Also adding the ability to customize via methods:
> org.apache.ignite.configuration.IgniteConfiguration#setDefaultCacheWarmup
> org.apache.ignite.configuration.CacheConfiguration#setCacheWarmup
>
> Which will allow for each cache to set implementation of cache warming up,
> both for a specific cache, and for all if necessary.
>
> I suggest adding an implementation of SequentialWarmup that will use [3].
>
> Questions, suggestions, comments?
>
> [1] -
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#afterLogicalUpdatesApplied
> [2] -
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.CacheRecoveryLifecycle#restorePartitionStates
> [3] -
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManager.CacheDataStore#preload
>
Re: New Committer: Sergey Chugunov
Hi, Well deserved! Keep it up, Sergey! Thanks, S. пт, 17 июл. 2020 г. в 14:36, Ivan Pavlukhin : > Sergey, congratulations! > > 2020-07-17 14:25 GMT+03:00, Petr Ivanov : > > Congratulations! > > > > > >> On 17 Jul 2020, at 14:14, Roman Kondakov > >> wrote: > >> > >> Sergey, congratulations! > >> > >> -- > >> Roman Kondakov > >> > >> On 17.07.2020 12:32, Dmitriy Pavlov wrote: > >>> Dear Ignite Community, > >>> The Project Management Committee (PMC) for Apache Ignite has invited > >>> Sergey > >>> Chugunov to become a committer and we are pleased to announce that he > >>> has > >>> accepted. > >>> Sergey has a long story of Ignite contributions. Besides the code > >>> contributions, Sergey has contributed the TCP Discovery Under The Hood > >>> wiki > >>> page, posted a blog post about running Apache Ignite on AWS, and also > >>> mentors newcomer contributors. > >>> 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. > >>> Sergey, congratulations on a new role in the Apache Ignite Community. > >>> Best Regards, > >>> Dmitriy Pavlov > >>> on behalf of Apache Ignite PMC > >>> P.S. this announce is a little bit overdue, but I guess Sergey's new > >>> role > >>> was not announced to the community. > > > > > > > -- > > Best regards, > Ivan Pavlukhin >
Re: New committer: Artem Budnikov
Hello Artem, Congratulations! You definitely deserve it. Thanks, S. чт, 16 июл. 2020 г. в 15:26, Ivan Pavlukhin : > Artem, my congratulations! > > 2020-07-16 15:10 GMT+03:00, Roman Kondakov : > > Congrats, Artem! > > > > -- > > Roman Kondakov > > > > On 16.07.2020 14:19, Ilya Kasnacheev wrote: > >> Hello! > >> > >> The Project Management Committee for Apache Ignite project has invited > >> Artem Budnikov to become a committer and we are pleased to announce that > >> he > >> has accepted. > >> > >> He is the person behind a monumental effort to keep Apache Ignite > >> documentation neat and tidy, which he does by writing, reviewing and > >> versioning most of docs on apacheignite.readme.io. > >> > >> Being a committer enables easier contribution to the project since it > >> makes > >> possible to merge your own, or other contributors', changes after the > >> review. This should enable better productivity. > >> > >> On behalf of Apache Ignite PMC, > >> > > > > > -- > > Best regards, > Ivan Pavlukhin >
Re: Checkstyle fails Build Apache Ignite - can we split it?
Hello Alex, > In my opinion checkstyle rules definitely should be checked as early as possible and by default should fail Ignite build. Well, perhaps I am wrong. Ok. > But for exceptional cases (which was mentioned by Slava), can we add some > "Run custom build" parameter on TC to be able to exclude "checkstyle" > profile from "~Build Apache Ignite~" configuration? WDYT? This is exactly what I wanted to say. Thank you, Alex! Regards, Slava. вт, 7 июл. 2020 г. в 13:01, Alex Plehanov : > Guys, > > In my opinion checkstyle rules definitely should be checked as early as > possible and by default should fail Ignite build. > But for exceptional cases (which was mentioned by Slava), can we add some > "Run custom build" parameter on TC to be able to exclude "checkstyle" > profile from "~Build Apache Ignite~" configuration? WDYT? > > вт, 7 июл. 2020 г. в 14:53, Вячеслав Коптилин : > > > Hi Maxim, > > > > > Why the auto-formatting procedure cannot be used for any PR you'd like > to > > run on TC? > > > Even more, you can remove all the rules from checkstyle XML config and > do > > all you want in the PR branch > > Yes, I can enable auto-formatting, which should be checked anyway, I can > > edit pom.xml every time, etc. > > > > My question is the following: Why can't this check be done in parallel > with > > other tasks? > > > > Yep, I see the argument mentioned by Nikolay - TeamCity capacity (we > should > > re-run all tests even though we rename a variable), but I don't see that > > our TC servers are overwhelmed for now. > > Perhaps, I am wrong and this argument (TC capacity) is more significant > > than it seems to me at first glance. > > > > Folks, please don't get me wrong. I am not against the code-style check > at > > all. I just want to get some freedom for dev branches only, if it is > > possible of course. > > > > Thanks, > > Slava. > > > > вт, 7 июл. 2020 г. в 12:21, Maxim Muzafarov : > > > > > Slava, > > > > > > Why the auto-formatting procedure cannot be used for any PR you'd like > > > to run on TC? Even more, you can remove all the rules from checkstyle > > > XML config and do all you want in the PR branch. > > > > > > On Tue, 7 Jul 2020 at 12:17, Вячеслав Коптилин < > slava.kopti...@gmail.com > > > > > > wrote: > > > > > > > > Hi Nikolay, > > > > > > > > > Why do you need to Run All on TC resources for this task? > > > > For instance, it may be a race that cannot be reproduced locally on > my > > > own > > > > hardware. > > > > (By the way, even though if I just want to start Cache1 suite, the > > > > Code-Style check executes anyway). > > > > > > > > > If we don’t want to follow the code style or considered it as a > > «waste > > > of > > > > the time» we should change it. > > > > This is absolutely not what I'm trying to say. I do not think, that > > code > > > > style is useless. I just want to say that this check can be done in > > > > parallel for dev branches, for example. > > > > > > > > Thanks, > > > > S. > > > > > > > > вт, 7 июл. 2020 г. в 11:49, Nikolay Izhikov : > > > > > > > > > > Let's assume that I want to implement a dirty fix of a bug, > check > > a > > > > > reproducer from the user list, etc. > > > > > > > > > > Why do you need to Run All on TC resources for this task? > > > > > > > > > > > I do not want to waste my time fixing all code style violations. > > > > > > > > > > I assume that you have the Ignite project locally because you edit > > > Ignite > > > > > source code. > > > > > If yes, then IntelliJ IDEA has an automatic code formatting and > does > > > all > > > > > the work for you. > > > > > > > > > > > Does this use-case look reasonable? > > > > > > > > > > Yes. > > > > > But, I still don’t see what is the issue here. > > > > > > > > > > If we don’t want to follow the code style or considered it as a > > «waste > > > of > > > > > the time» we should change it. > > > > > As simple as that. > > > > > > > > > > But, we should force the code style
Re: Checkstyle fails Build Apache Ignite - can we split it?
> > I am not against the code-style check at all. > Yes, you are :) But it’s ok No, I am not :) > You can take a look at the commits that introduced checks and how many files were touched. I really appreciate this, Nikolay. Thanks, S. вт, 7 июл. 2020 г. в 13:04, Nikolay Izhikov : > > Why can't this check be done in parallel with other tasks? > > Because when we contribute code to Ignite we must follow code style. > > > I am not against the code-style check at all. > > Yes, you are :) But it’s ok > > > I just want to get some freedom for dev branches only, if it is possible > of course. > > It’s not about freedom - you are free to run any checks you want on TC. > It’s about project codebase consistency. > > No long time ago we don’t have TC bot or checkstyle plugin. > That leads us to new and new tests failures and code style violations. > > You can take a look at the commits that introduced checks and how many > files were touched. > We just ignore our own rules without checks. > > > https://github.com/apache/ignite/commit/2fbbb676386515ea881e4e61f08864d6bc93225a > > https://github.com/apache/ignite/commit/2a85925f1705fbad36b5421c0ca5cf9de9a29658 > > https://github.com/apache/ignite/commit/d63f4d3569dcb387394d367a7f00aaf35f1b288e > > > > > 7 июля 2020 г., в 12:52, Вячеслав Коптилин > написал(а): > > > > Hi Maxim, > > > >> Why the auto-formatting procedure cannot be used for any PR you'd like > to > > run on TC? > >> Even more, you can remove all the rules from checkstyle XML config and > do > > all you want in the PR branch > > Yes, I can enable auto-formatting, which should be checked anyway, I can > > edit pom.xml every time, etc. > > > > My question is the following: Why can't this check be done in parallel > with > > other tasks? > > > > Yep, I see the argument mentioned by Nikolay - TeamCity capacity (we > should > > re-run all tests even though we rename a variable), but I don't see that > > our TC servers are overwhelmed for now. > > Perhaps, I am wrong and this argument (TC capacity) is more significant > > than it seems to me at first glance. > > > > Folks, please don't get me wrong. I am not against the code-style check > at > > all. I just want to get some freedom for dev branches only, if it is > > possible of course. > > > > Thanks, > > Slava. > > > > вт, 7 июл. 2020 г. в 12:21, Maxim Muzafarov : > > > >> Slava, > >> > >> Why the auto-formatting procedure cannot be used for any PR you'd like > >> to run on TC? Even more, you can remove all the rules from checkstyle > >> XML config and do all you want in the PR branch. > >> > >> On Tue, 7 Jul 2020 at 12:17, Вячеслав Коптилин < > slava.kopti...@gmail.com> > >> wrote: > >>> > >>> Hi Nikolay, > >>> > >>>> Why do you need to Run All on TC resources for this task? > >>> For instance, it may be a race that cannot be reproduced locally on my > >> own > >>> hardware. > >>> (By the way, even though if I just want to start Cache1 suite, the > >>> Code-Style check executes anyway). > >>> > >>>> If we don’t want to follow the code style or considered it as a «waste > >> of > >>> the time» we should change it. > >>> This is absolutely not what I'm trying to say. I do not think, that > code > >>> style is useless. I just want to say that this check can be done in > >>> parallel for dev branches, for example. > >>> > >>> Thanks, > >>> S. > >>> > >>> вт, 7 июл. 2020 г. в 11:49, Nikolay Izhikov : > >>> > >>>>> Let's assume that I want to implement a dirty fix of a bug, check a > >>>> reproducer from the user list, etc. > >>>> > >>>> Why do you need to Run All on TC resources for this task? > >>>> > >>>>> I do not want to waste my time fixing all code style violations. > >>>> > >>>> I assume that you have the Ignite project locally because you edit > >> Ignite > >>>> source code. > >>>> If yes, then IntelliJ IDEA has an automatic code formatting and does > >> all > >>>> the work for you. > >>>> > >>>>> Does this use-case look reasonable? > >>>> > >>>> Yes. > >>>> But, I still don’t see what is the issue here. > >>>>
Re: Checkstyle fails Build Apache Ignite - can we split it?
Hi Maxim, > Why the auto-formatting procedure cannot be used for any PR you'd like to run on TC? > Even more, you can remove all the rules from checkstyle XML config and do all you want in the PR branch Yes, I can enable auto-formatting, which should be checked anyway, I can edit pom.xml every time, etc. My question is the following: Why can't this check be done in parallel with other tasks? Yep, I see the argument mentioned by Nikolay - TeamCity capacity (we should re-run all tests even though we rename a variable), but I don't see that our TC servers are overwhelmed for now. Perhaps, I am wrong and this argument (TC capacity) is more significant than it seems to me at first glance. Folks, please don't get me wrong. I am not against the code-style check at all. I just want to get some freedom for dev branches only, if it is possible of course. Thanks, Slava. вт, 7 июл. 2020 г. в 12:21, Maxim Muzafarov : > Slava, > > Why the auto-formatting procedure cannot be used for any PR you'd like > to run on TC? Even more, you can remove all the rules from checkstyle > XML config and do all you want in the PR branch. > > On Tue, 7 Jul 2020 at 12:17, Вячеслав Коптилин > wrote: > > > > Hi Nikolay, > > > > > Why do you need to Run All on TC resources for this task? > > For instance, it may be a race that cannot be reproduced locally on my > own > > hardware. > > (By the way, even though if I just want to start Cache1 suite, the > > Code-Style check executes anyway). > > > > > If we don’t want to follow the code style or considered it as a «waste > of > > the time» we should change it. > > This is absolutely not what I'm trying to say. I do not think, that code > > style is useless. I just want to say that this check can be done in > > parallel for dev branches, for example. > > > > Thanks, > > S. > > > > вт, 7 июл. 2020 г. в 11:49, Nikolay Izhikov : > > > > > > Let's assume that I want to implement a dirty fix of a bug, check a > > > reproducer from the user list, etc. > > > > > > Why do you need to Run All on TC resources for this task? > > > > > > > I do not want to waste my time fixing all code style violations. > > > > > > I assume that you have the Ignite project locally because you edit > Ignite > > > source code. > > > If yes, then IntelliJ IDEA has an automatic code formatting and does > all > > > the work for you. > > > > > > > Does this use-case look reasonable? > > > > > > Yes. > > > But, I still don’t see what is the issue here. > > > > > > If we don’t want to follow the code style or considered it as a «waste > of > > > the time» we should change it. > > > As simple as that. > > > > > > But, we should force the code style as early as we can. > > > I think we should fail maven local build on code style violations. > > > > > > > 7 июля 2020 г., в 11:28, Вячеслав Коптилин > > > > написал(а): > > > > > > > > Nikolay, > > > > > > > > There is *NO *intention to ignore code style violations and do merge > PRs > > > > into the master branch without fixing them. > > > > > > > > Let's assume that I want to implement a dirty fix of a bug, check a > > > > reproducer from the user list, etc. > > > > And I do not have the intention to merge that into the master branch > as > > > is, > > > > however, I do not want to waste my time fixing all code style > violations. > > > > Does this use-case look reasonable? > > > > > > > > Thanks, > > > > Slava. > > > > > > > > вт, 7 июл. 2020 г. в 11:07, Nikolay Izhikov : > > > > > > > >> Slava. > > > >> > > > >> All contributors should follow our code style during their > contribution. > > > >> For now, we have an automatic PR check that is integrated to the > GitHub > > > >> interface. > > > >> > > > >> I don’t see any issue here. > > > >> All open-source project that I know, uses the same approach. > > > >> > > > >> Anyway, If some of the experienced community members is interested > in > > > the > > > >> particular contribution he or she can help a newcomer with the code > > > style - > > > >> GitHub interface has the edit button even for someone else’s PR’s > > > >> > > > >> &g
Re: Checkstyle fails Build Apache Ignite - can we split it?
Hi Nikolay, > Why do you need to Run All on TC resources for this task? For instance, it may be a race that cannot be reproduced locally on my own hardware. (By the way, even though if I just want to start Cache1 suite, the Code-Style check executes anyway). > If we don’t want to follow the code style or considered it as a «waste of the time» we should change it. This is absolutely not what I'm trying to say. I do not think, that code style is useless. I just want to say that this check can be done in parallel for dev branches, for example. Thanks, S. вт, 7 июл. 2020 г. в 11:49, Nikolay Izhikov : > > Let's assume that I want to implement a dirty fix of a bug, check a > reproducer from the user list, etc. > > Why do you need to Run All on TC resources for this task? > > > I do not want to waste my time fixing all code style violations. > > I assume that you have the Ignite project locally because you edit Ignite > source code. > If yes, then IntelliJ IDEA has an automatic code formatting and does all > the work for you. > > > Does this use-case look reasonable? > > Yes. > But, I still don’t see what is the issue here. > > If we don’t want to follow the code style or considered it as a «waste of > the time» we should change it. > As simple as that. > > But, we should force the code style as early as we can. > I think we should fail maven local build on code style violations. > > > 7 июля 2020 г., в 11:28, Вячеслав Коптилин > написал(а): > > > > Nikolay, > > > > There is *NO *intention to ignore code style violations and do merge PRs > > into the master branch without fixing them. > > > > Let's assume that I want to implement a dirty fix of a bug, check a > > reproducer from the user list, etc. > > And I do not have the intention to merge that into the master branch as > is, > > however, I do not want to waste my time fixing all code style violations. > > Does this use-case look reasonable? > > > > Thanks, > > Slava. > > > > вт, 7 июл. 2020 г. в 11:07, Nikolay Izhikov : > > > >> Slava. > >> > >> All contributors should follow our code style during their contribution. > >> For now, we have an automatic PR check that is integrated to the GitHub > >> interface. > >> > >> I don’t see any issue here. > >> All open-source project that I know, uses the same approach. > >> > >> Anyway, If some of the experienced community members is interested in > the > >> particular contribution he or she can help a newcomer with the code > style - > >> GitHub interface has the edit button even for someone else’s PR’s > >> > >> > >>> 7 июля 2020 г., в 11:01, Вячеслав Коптилин > >> написал(а): > >>> > >>> Hello Nikolay, > >>> > >>>> Because any code style violations should be fixed before the merge. > >>>> Therefore after the fix, you must rerun TC. > >>>> This means that running heavy suites when code style is violated is a > >>> waste of the resources. > >>> This makes sense, however, to be honest, I don't see that our team city > >>> servers are really busy. > >>> > >>>> Why do you want to violate code style rules in your PR? > >>> Please take a look at the original e-mail from Ilya: > >>>> This means that I have completely lost an option to run tests against > >>> pull > >>>> requests by new contributors - they usually compile but will not pass > >>>> Checkstyle. That's a blocker. > >>> > >>> This issue has also been discussed here: > >>> > >> > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Separate-code-sanity-check-and-build-task-td47003.html > >>> > >>> Thanks, > >>> Slava. > >>> > >>> > >>> вт, 7 июл. 2020 г. в 10:47, Nikolay Izhikov : > >>> > >>>> All checks just force rules we agreed on. > >>>> > >>>>> Why this check is so important? Why do you think it is more important > >>>> than all other tasks/tests? > >>>> > >>>> Because any code style violations should be fixed before the merge. > >>>> Therefore after the fix, you must rerun TC. > >>>> This means that running heavy suites when code style is violated is a > >>>> waste of the resources. > >>>> > >>>> Why do you want to violate code style rules in your PR? > >>>> > >
Re: Checkstyle fails Build Apache Ignite - can we split it?
Nikolay, There is *NO *intention to ignore code style violations and do merge PRs into the master branch without fixing them. Let's assume that I want to implement a dirty fix of a bug, check a reproducer from the user list, etc. And I do not have the intention to merge that into the master branch as is, however, I do not want to waste my time fixing all code style violations. Does this use-case look reasonable? Thanks, Slava. вт, 7 июл. 2020 г. в 11:07, Nikolay Izhikov : > Slava. > > All contributors should follow our code style during their contribution. > For now, we have an automatic PR check that is integrated to the GitHub > interface. > > I don’t see any issue here. > All open-source project that I know, uses the same approach. > > Anyway, If some of the experienced community members is interested in the > particular contribution he or she can help a newcomer with the code style - > GitHub interface has the edit button even for someone else’s PR’s > > > > 7 июля 2020 г., в 11:01, Вячеслав Коптилин > написал(а): > > > > Hello Nikolay, > > > >> Because any code style violations should be fixed before the merge. > >> Therefore after the fix, you must rerun TC. > >> This means that running heavy suites when code style is violated is a > > waste of the resources. > > This makes sense, however, to be honest, I don't see that our team city > > servers are really busy. > > > >> Why do you want to violate code style rules in your PR? > > Please take a look at the original e-mail from Ilya: > >> This means that I have completely lost an option to run tests against > > pull > >> requests by new contributors - they usually compile but will not pass > >> Checkstyle. That's a blocker. > > > > This issue has also been discussed here: > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Separate-code-sanity-check-and-build-task-td47003.html > > > > Thanks, > > Slava. > > > > > > вт, 7 июл. 2020 г. в 10:47, Nikolay Izhikov : > > > >> All checks just force rules we agreed on. > >> > >>> Why this check is so important? Why do you think it is more important > >> than all other tasks/tests? > >> > >> Because any code style violations should be fixed before the merge. > >> Therefore after the fix, you must rerun TC. > >> This means that running heavy suites when code style is violated is a > >> waste of the resources. > >> > >> Why do you want to violate code style rules in your PR? > >> > >> I think instead of hiding style errors we should make our code style > >> comfortable for everyone. > >> Can you, please, write - what part of the code style hurts you? > >> > >> > >>> 7 июля 2020 г., в 10:39, Вячеслав Коптилин > >> написал(а): > >>> > >>> Hello Maxim, > >>> > >>>> Why do you think that splitting the checkstyle build is better option > >>> than fixing code style issues reporting by the checkstyle plugin? > >>> Why do you think that Ilya talks that code style errors should not be > >> fixed? > >>> > >>> It looks weird to me that we do not even start the tests if check style > >>> plugin reports violations. > >>> Why can't this check be done in parallel with the tests and reported by > >>> mtcga bot? > >>> Why this check is so important? Why do you think it is more important > >> than > >>> all other tasks/tests? > >>> > >>> Thanks, > >>> Slava. > >>> > >>> пн, 6 июл. 2020 г. в 20:34, Maxim Muzafarov : > >>> > >>>> Hello Ilya, > >>>> > >>>> Why do you think that splitting the checkstyle build is better option > >>>> than fixing code style issues reporting by the checkstyle plugin? > >>>> > >>>> On Mon, 6 Jul 2020 at 19:43, Ilya Kasnacheev < > ilya.kasnach...@gmail.com > >>> > >>>> wrote: > >>>>> > >>>>> Hello! > >>>>> > >>>>> I have just noticed today that Checkstyle will fail Apache Ignite > >> build: > >>>>> > >>>> > >> > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BuildApacheIgnite/5443282?buildTab=log=3=683.4289 > >>>>> > >>>>> This means that I have completely lost an option to run tests against > >>>> pull > >>>>> requests by new contributors - they usually compile but will not pass > >>>>> Checkstyle. That's a blocker. > >>>>> > >>>>> Can we please split Checkstyle as a separate build which is triggered > >>>> with > >>>>> Run All? > >>>>> I think we even have > >>>>> > >>>> > >> > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CheckCodeStyle?mode=builds#all-projects > >>>>> > >>>>> WDYT? > >>>>> > >>>>> Regards, > >>>>> -- > >>>>> Ilya Kasnacheev > >>>> > >> > >> > >
Re: Checkstyle fails Build Apache Ignite - can we split it?
Hello Nikolay, > Because any code style violations should be fixed before the merge. > Therefore after the fix, you must rerun TC. > This means that running heavy suites when code style is violated is a waste of the resources. This makes sense, however, to be honest, I don't see that our team city servers are really busy. > Why do you want to violate code style rules in your PR? Please take a look at the original e-mail from Ilya: > This means that I have completely lost an option to run tests against pull > requests by new contributors - they usually compile but will not pass > Checkstyle. That's a blocker. This issue has also been discussed here: http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Separate-code-sanity-check-and-build-task-td47003.html Thanks, Slava. вт, 7 июл. 2020 г. в 10:47, Nikolay Izhikov : > All checks just force rules we agreed on. > > > Why this check is so important? Why do you think it is more important > than all other tasks/tests? > > Because any code style violations should be fixed before the merge. > Therefore after the fix, you must rerun TC. > This means that running heavy suites when code style is violated is a > waste of the resources. > > Why do you want to violate code style rules in your PR? > > I think instead of hiding style errors we should make our code style > comfortable for everyone. > Can you, please, write - what part of the code style hurts you? > > > > 7 июля 2020 г., в 10:39, Вячеслав Коптилин > написал(а): > > > > Hello Maxim, > > > >> Why do you think that splitting the checkstyle build is better option > > than fixing code style issues reporting by the checkstyle plugin? > > Why do you think that Ilya talks that code style errors should not be > fixed? > > > > It looks weird to me that we do not even start the tests if check style > > plugin reports violations. > > Why can't this check be done in parallel with the tests and reported by > > mtcga bot? > > Why this check is so important? Why do you think it is more important > than > > all other tasks/tests? > > > > Thanks, > > Slava. > > > > пн, 6 июл. 2020 г. в 20:34, Maxim Muzafarov : > > > >> Hello Ilya, > >> > >> Why do you think that splitting the checkstyle build is better option > >> than fixing code style issues reporting by the checkstyle plugin? > >> > >> On Mon, 6 Jul 2020 at 19:43, Ilya Kasnacheev > > >> wrote: > >>> > >>> Hello! > >>> > >>> I have just noticed today that Checkstyle will fail Apache Ignite > build: > >>> > >> > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BuildApacheIgnite/5443282?buildTab=log=3=683.4289 > >>> > >>> This means that I have completely lost an option to run tests against > >> pull > >>> requests by new contributors - they usually compile but will not pass > >>> Checkstyle. That's a blocker. > >>> > >>> Can we please split Checkstyle as a separate build which is triggered > >> with > >>> Run All? > >>> I think we even have > >>> > >> > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CheckCodeStyle?mode=builds#all-projects > >>> > >>> WDYT? > >>> > >>> Regards, > >>> -- > >>> Ilya Kasnacheev > >> > >
Re: Checkstyle fails Build Apache Ignite - can we split it?
Hello Maxim, > Why do you think that splitting the checkstyle build is better option than fixing code style issues reporting by the checkstyle plugin? Why do you think that Ilya talks that code style errors should not be fixed? It looks weird to me that we do not even start the tests if check style plugin reports violations. Why can't this check be done in parallel with the tests and reported by mtcga bot? Why this check is so important? Why do you think it is more important than all other tasks/tests? Thanks, Slava. пн, 6 июл. 2020 г. в 20:34, Maxim Muzafarov : > Hello Ilya, > > Why do you think that splitting the checkstyle build is better option > than fixing code style issues reporting by the checkstyle plugin? > > On Mon, 6 Jul 2020 at 19:43, Ilya Kasnacheev > wrote: > > > > Hello! > > > > I have just noticed today that Checkstyle will fail Apache Ignite build: > > > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BuildApacheIgnite/5443282?buildTab=log=3=683.4289 > > > > This means that I have completely lost an option to run tests against > pull > > requests by new contributors - they usually compile but will not pass > > Checkstyle. That's a blocker. > > > > Can we please split Checkstyle as a separate build which is triggered > with > > Run All? > > I think we even have > > > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CheckCodeStyle?mode=builds#all-projects > > > > WDYT? > > > > Regards, > > -- > > Ilya Kasnacheev >
Re: [VOTE] Stop Maintenance of Ignite WebConsole
+1 Thanks, S. ср, 13 мая 2020 г. в 08:48, Nikolay Izhikov : > +1 > > ср, 13 мая 2020 г., 07:35 Alexey Zinoviev : > > > +1 > > > > ср, 13 мая 2020 г., 5:52 Saikat Maitra : > > > > > +1 > > > > > > Regards > > > Saikat > > > > > > On Tue, 12 May 2020 at 7:03 PM, Denis Magda wrote: > > > > > > > Igniters, > > > > > > > > As it was discussed earlier [1], it feels like we abandoned the > > > development > > > > and maintenance of Ignite WebConsole. The users keep creating tickets > > for > > > > improvements and report issues, while the backlog only keeps growing > > with > > > > no reaction on our end. > > > > > > > > With this vote, we hope to put WebConsole's development and > maintenance > > > on > > > > hold *officially* by moving it to a separate Ignite repository and > > > closing > > > > all WebConsole-related tickets with a proper maintenance > > discontinuation > > > > notice. That's a gentle phase-out. If anybody joins the community and > > > > decides to resurrect the project they will have a chance to do that. > > > > Otherwise, WebConsole ends up on a graveyard eventually. > > > > > > > > Please cast your vote: > > > > +1 - to discontinue Ignite WebConsole's development and maintenance > by > > > > moving to a separate Ignite repository. > > > > -1 - against this course of action. > > > > > > > > I'll let this vote last for 7 days and close it on May 18th. > > > > > > > > > > > > [1] > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-WebConsole-Deprecation-td47259.html > > > > > > > > - > > > > Denis > > > > > > > > > >
Re: [ANNOUNCE] New Committer: Taras Ledkov
Hooray! Congratulations, Taras! Well deserved, keep going! Thanks, S. вт, 12 мая 2020 г. в 19:09, Dmitriy Pavlov : > Hello Ignite Community, > > > > The Project Management Committee (PMC) for Apache Ignite has invited Taras > Ledkov to become a committer and we are pleased to announce that he has > accepted. > > > Taras is an Ignite SQL veteran who knows in detail current Ignite - H2 > integration and binary serialization, actively participates in JDBC and > thin client protocol development, he is eager to help users on the user > list within his area of expertise. > > > > 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. > > > > Taras, thank you for all your efforts, congratulations and welcome on > board! > . > > > > Best Regards, > > Dmitriy Pavlov > > on behalf of Apache Ignite PMC >
Re: [ANNOUNCE] New PMC member: Maxim Muzafarov
Hi Maxim, My congratulations! Thanks, S. сб, 9 мая 2020 г. в 07:12, Denis Magda : > Congrats, Maxim. Well deserved! > > - > Denis > > > On Thu, May 7, 2020 at 4:47 AM Dmitriy Pavlov wrote: > > > The Project Management Committee (PMC) for Apache Ignite > > > > has invited Maxim Muzafarov to become new PMC member and we are pleased > to > > announce that he has accepted. > > > > > > > > Maxim is active dev list participant, speaker at meetups, and contributes > > to additional checks of the product using travis and started new file > > rebalance. Maxim did a fantastic job to make release 2.8 possible > > > > > > > > Being a PMC member enables assistance with the management > > > > and to guide the direction of the project. > > > > Maxim, congrats with new role and keep the pace ! > > > > > > > > Best Regards, > > > > Dmitriy Pavlov > > > > on behalf of Apache Ignite PMC > > >
Re: Moving binary metadata to PDS storage folder
Hello Semyon, This is a good and long-awaited improvement! Thank you for your efforts! Thanks, S. вт, 12 мая 2020 г. в 15:11, Данилов Семён : > Hello! > > I would like to propose moving /binary_meta and /marshaller folders to the > PDS folder. > > Motivation: data, directly related to the persistence, is stored outside > the persistence dir, which can lead to various issues and also is not very > convenient to use. In particular, with k8s, deployment disk that is > attached to a container can not be accessed from other containers or > outside of k8s. In case if support will need to drop persistence except > data, there will be no way to recover due to binary metadata is required to > process PDS files. > > I created an issue (https://issues.apache.org/jira/browse/IGNITE-12994) and a > pull request(https://github.com/apache/ignite/pull/7792) that fixes the > issue. > > In that PR I made the following: > > > * store binary meta and marshaller data inside db/ folder > * if binary meta of marshaller are found in "legacy" locations -- > safely move them to new locations during the node startup > > > Kind regards, > > Semyon Danilov. >
Re: [DISCUSSION] Ignite WebConsole Deprecation
Hello, +1 to remove this component or move it to a separate repository if someone wants to maintain it. In case the web console provides useful features, we should consider how to add them to our command-line utilities, if possible. Thanks, Slava. ср, 6 мая 2020 г. в 16:10, Nikolay Izhikov : > Hello. > > +1 to remove any graphical utilities from the Ignite core. > I think we should maintain and support only cmd, JMX, and other «core» > tools. > > We shouldn't waste our resources on supporting pretty looking UI tools. > > > > 2 мая 2020 г., в 04:05, Saikat Maitra > написал(а): > > > > Hello Denis, > > > > I am thinking if we should move web-console to a separate repo like > > ignite-web-console. In my opinion the tech stack we have in web-console > > like npm, nodejs and Mondodb etc are little different and can be hosted > as > > a separate project in a git repo. > > > > I had used web-console for streamers project and found it helpful in > > creating table schema and execute sql queries and also to do cache > lookup. > > > > https://github.com/samaitra/streamers > > > > If we continue to find that usage of ignite-web-console is limited then > we > > can plan moving ignite-web-console in Apache Attic > > > > https://attic.apache.org/ > > > > Please let me know your thoughts. > > > > Regards, > > Saikat > > > > > > > > On Fri, May 1, 2020 at 12:43 PM Denis Magda wrote: > > > >> Igniters, > >> > >> I would like to hear your opinion on what we should do with Ignite > >> WebConsole. > >> > >> To my knowledge, we don't have active maintainers of the component, and > a > >> list of issues is piling up [1]. Users even report that the docker > images > >> have not been updated for more than a year [2]. > >> > >> Personally, I share the opinion of those who believe the community > needs to > >> provide and support all the essential tooling (metrics and tracing API, > >> command-line tool) while the UI tools are not our business. There is a > >> myriad of UI tools Ignite can be monitored and traced with. Users > already > >> have plenty of choices. > >> > >> What are your thoughts? Probably, some of you want to become > maintainers of > >> the component. Otherwise, we should let the tool go. > >> > >> [1] > >> > >> > https://issues.apache.org/jira/browse/IGNITE-12923?jql=project%20%3D%20IGNITE%20AND%20text%20~%20%22web%20console%22%20AND%20status%20%3D%20Open%20and%20type%20%3D%20Bug%20ORDER%20BY%20createdDate%20 > >> [2] https://issues.apache.org/jira/browse/IGNITE-12923 > >> > >> - > >> Denis > >> > >
Re: Tool for performance statistics reports
; >> reuse. > >> > >> пт, 24 апр. 2020 г. в 18:59, Ilya Kasnacheev >: > >>> > >>> Hello! > >>> > >>> I suggest that it's one of the places where it could be put instead of > >>> adding a new tool. > >>> > >>> Regards, > >>> -- > >>> Ilya Kasnacheev > >>> > >>> > >>> пт, 24 апр. 2020 г. в 18:56, Nikita Amelchev : > >>> > >>>> Ilya, > >>>> > >>>> You suggest using control.sh to build the report? > >>>> > >>>> пт, 24 апр. 2020 г. в 18:20, Ilya Kasnacheev < > >> ilya.kasnach...@gmail.com>: > >>>>> > >>>>> Hello! > >>>>> > >>>>> You need to throw in control.sh also, which does some kind of > >> statistics > >>>>> too, such as idle_verify. > >>>>> > >>>>> Regards, > >>>>> -- > >>>>> Ilya Kasnacheev > >>>>> > >>>>> > >>>>> пт, 24 апр. 2020 г. в 18:06, Вячеслав Коптилин < > >> slava.kopti...@gmail.com > >>>>> : > >>>>> > >>>>>> Hello Nikita, > >>>>>> > >>>>>> Perhaps, I am missing something... > >>>>>> Apache Ignite already has a web-console tool. Do we want to > >> improve the > >>>>>> existing tool instead of creating a new one? > >>>>>> It seems to me, this can be confusing for users. > >>>>>> - visor (which is deprecated) > >>>>>> - web-console (to be honest, I don't quite understand the status > >> of > >>>> this > >>>>>> tool) > >>>>>> - new ignite-profiling (which is a monitoring tool as well, > >> judging > >>>> by the > >>>>>> provided link [1] ) > >>>>>> > >>>>>> I am not against the new tool, I just want to understand the > >>>> motivation to > >>>>>> not improve the existing sub-projects. > >>>>>> > >>>>>> [1] > >>>>>> > >>>>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool > >>>>>> > >>>>>> Thanks, > >>>>>> S. > >>>>>> > >>>>>> пт, 24 апр. 2020 г. в 14:58, Nikita Amelchev >>> : > >>>>>> > >>>>>>> Hi, Igniters. > >>>>>>> > >>>>>>> I'm working on cluster profiling and the tool for creating a > >>>>>>> performance report. [1] I have prepared PoC based on performance > >>>>>>> logging to a separate category of Ignite log. The report > >> contains: > >>>>>>> > >>>>>>> - Cache operations and its distribution by types [2] > >>>>>>> - Transactions and histogram of durations [3] > >>>>>>> - SQL and Scan query statistics, top of slowest queries, logical > >> and > >>>>>>> physical reads by query [4] > >>>>>>> - Compute statistics, top of slowest tasks and their jobs [5] > >>>>>>> Soon I will add: > >>>>>>> - Topology and Ignite versions info > >>>>>>> - Client ID in case of operations from clients > >>>>>>> > >>>>>>> For now, I'm developing a binary logging format to reduce the > >> effect > >>>>>>> on performance. I'll try to reuse Ignite mechanisms. > >>>>>>> > >>>>>>> I would like to hear suggestions for the profiling and the > >>>> performance > >>>>>>> report. > >>>>>>> > >>>>>>> [1] > >>>>>>> > >>>>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool > >>>>>>> [2] > >>>>>>> > >>>>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool?preview=/145723859/148647581/p1.png > >>>>>>> [3] > >>>>>>> > >>>>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool?preview=/145723859/148647582/p2.png > >>>>>>> [4] > >>>>>>> > >>>>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool?preview=/145723859/148647583/p3.png > >>>>>>> [5] > >>>>>>> > >>>>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool?preview=/145723859/152112279/p5.png > >>>>>>> > >>>>>>> -- > >>>>>>> Best wishes, > >>>>>>> Amelchev Nikita > >>>>>>> > >>>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Best wishes, > >>>> Amelchev Nikita > >>>> > >> > >> > >> > >> -- > >> Best wishes, > >> Amelchev Nikita > >> > >
Re: Tool for performance statistics reports
Hello Nikita, Perhaps, I am missing something... Apache Ignite already has a web-console tool. Do we want to improve the existing tool instead of creating a new one? It seems to me, this can be confusing for users. - visor (which is deprecated) - web-console (to be honest, I don't quite understand the status of this tool) - new ignite-profiling (which is a monitoring tool as well, judging by the provided link [1] ) I am not against the new tool, I just want to understand the motivation to not improve the existing sub-projects. [1] https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool Thanks, S. пт, 24 апр. 2020 г. в 14:58, Nikita Amelchev : > Hi, Igniters. > > I'm working on cluster profiling and the tool for creating a > performance report. [1] I have prepared PoC based on performance > logging to a separate category of Ignite log. The report contains: > > - Cache operations and its distribution by types [2] > - Transactions and histogram of durations [3] > - SQL and Scan query statistics, top of slowest queries, logical and > physical reads by query [4] > - Compute statistics, top of slowest tasks and their jobs [5] > Soon I will add: > - Topology and Ignite versions info > - Client ID in case of operations from clients > > For now, I'm developing a binary logging format to reduce the effect > on performance. I'll try to reuse Ignite mechanisms. > > I would like to hear suggestions for the profiling and the performance > report. > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool > [2] > https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool?preview=/145723859/148647581/p1.png > [3] > https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool?preview=/145723859/148647582/p2.png > [4] > https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool?preview=/145723859/148647583/p3.png > [5] > https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool?preview=/145723859/152112279/p5.png > > -- > Best wishes, > Amelchev Nikita >
Re: Apache Ignite 2.8.1 RELEASE [Time, Scope, Manager]
Folks, I'd like to add ticket IGNITE-12805 "NullPointerException on node restart when 3rd party persistence and Ignite native persistence are used" to ignite-2.8.1 scope. [1] https://issues.apache.org/jira/browse/IGNITE-12805 Thanks, S. вт, 7 апр. 2020 г. в 19:57, Ilya Kasnacheev : > Hello! > > Done! > > Regards, > -- > Ilya Kasnacheev > > > вт, 7 апр. 2020 г. в 12:31, Sergey : > > > Hi, > > > > I'm proposing to add > > https://issues.apache.org/jira/browse/IGNITE-12549 (fix iterators/scan > > queries for replicated caches) > > to 2.8.1. > > > > Best regards, > > Sergey Kosarev. > > > > > > вс, 5 апр. 2020 г. в 01:22, Saikat Maitra : > > > > > Hi, > > > > > > I observed that we already have release 2.8.1 branch > > > https://github.com/apache/ignite/tree/ignite-2.8.1 > > > > > > In that case we should be ok to merge these 2 open PRs in master to > make > > it > > > available for 2.9.0 release. > > > > > > https://github.com/apache/ignite/pull/7240 > > > https://github.com/apache/ignite/pull/7227 > > > > > > Can you please review and confirm? > > > > > > Regards, > > > Saikat > > > > > > On Fri, Mar 20, 2020 at 8:19 AM Maxim Muzafarov > > wrote: > > > > > > > Igniters, > > > > > > > > I support Nikolay Izhikov as the release manager of 2.8.1 Apache > > > > Ignite release. Since no one else of committers, PMCs expressed a > > > > desire to lead this release I think we can close this question and > > > > focus on the release scope and dates. > > > > > > > > > > > > Ivan, > > > > > > > > You helped me configuring TC.Bot that time, can you please help again > > > > and set `ignite-2.8.1` branch for guard under TC.Bot [1]? We should > > > > start collecting TC statistics for the release branch as early as > > > > possible. > > > > > > > > > > > > [1] https://mtcga.gridgain.com/guard.html > > > > > > > > On Fri, 20 Mar 2020 at 14:48, Taras Ledkov > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > I propose to add the issue [1] related to SQL query execution to > this > > > > scope. > > > > > > > > > > We had omitted this case and Ignite 2.8 contains serious SQL issue: > > > > > cursor of a local query is not thread-safe. > > > > > It is root cause of several SQL issue, e.g. JDBC thin client cannot > > > > > execute query from replicated cache, > > > > > PME may hang after execute such queries from JDBC thin, etc. > > > > > > > > > > [1]. https://issues.apache.org/jira/browse/IGNITE-12800 > > > > > > > > > > On 19.03.2020 17:52, Denis Magda wrote: > > > > > > Igniters, > > > > > > > > > > > > As long as 2.8.1 is inevitable and we already keep adding > critical > > > > issues > > > > > > to the working queue, let's settle on the release time frames and > > > > decide > > > > > > who will be a release manager. This is the time proposed by Maxim > > > and, > > > > > > personally, I concur with such a schedule: > > > > > > > > > > > > - Scope Freeze: April 15, 2020 > > > > > > - Code Freeze: April 22, 2020 > > > > > > - Voting Date: April 27, 2020 > > > > > > - Release Date: May 1, 2020 > > > > > > > > > > > > Do we agree on this time? Is there anybody who ready to drive the > > > > release > > > > > > as a release manager? > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Thu, Mar 19, 2020 at 5:50 AM Sergey Antonov < > > > > antonovserge...@gmail.com> > > > > > > wrote: > > > > > > > > > > > >> Folks, > > > > > >> > > > > > >> I'd like to add ticket IGNITE-12774 Transaction hangs after too > > many > > > > open > > > > > >> files NIO exception [1] to ignite-2.8.1 scope. > > > > > >> > > > > > >> [1] https://issues.apache.org/jira/browse/IGNITE-12774 > > > > > >> > > > > > >> ср, 18 мар. 2020 г. в 16:53, Maxim Muzafarov >: > > > > > >> > > > > > >>> Folks, > > > > > >>> > > > > > >>> Can we add ignite-2.8.1 [2] branch under TC.Bot protection [1]? > > > > > >>> > > > > > >>> > > > > > >>> [1] https://mtcga.gridgain.com/guard.html > > > > > >>> [2] https://github.com/apache/ignite/tree/ignite-2.8.1 > > > > > >>> > > > > > >>> On Mon, 16 Mar 2020 at 16:32, Alexey Goncharuk > > > > > >>> wrote: > > > > > Folks, > > > > > > > > > > I've walked through all the commits to master since 2.8 branch > > was > > > > cut > > > > > >>> and > > > > > filtered some tickets that in my opinion are worth including > to > > > > 2.8.1 > > > > > release below (note that they are ready end the effort of > > > including > > > > > >> them > > > > > >>> to > > > > > the release should be low as long as there are no implicit > > > > dependencies > > > > > between tickets). Please share your opinion on whether we > should > > > > > >> include > > > > > them to the 2.8.1. > > > > > > > > > > IGNITE-12717 SQL: index creation refactoring > > > > > IGNITE-12590 MERGE INTO query is failing on Ignite client node > > > > > IGNITE-12671 Update of partition's states can stuck when > > rebalance > > > > > completed during
Re: Data vanished from cluster after INACTIVE/ACTIVE switch
Hello Vladimir,
> onto anolugous
> @param forceDeactivation If {@code true}, cluster deactivation will be
forced. //Deactivation clears in-memory caches (without persistence)
including the system caches.
My idea was about providing a link to one place with a complete description
instead of copy
> We might include this fix in the last [1].
It is up to you, Vladimir.
Thanks,
S.
пт, 3 апр. 2020 г. в 15:42, Vladimir Steshin :
> Slava, hello.
>
>
> All right, since we have in public API several
>
> /* Deactivation clears in-memory caches (without persistence) including
> the system caches./
>
> We should change in the internals
>
> /@param forceDeactivation If {@code true}, cluster deactivation will
> be forced./
>
> onto anolugous
>
> /@param forceDeactivation If {@code true}, cluster deactivation will
> be forced. //Deactivation clears in-memory caches (without persistence)
> including the system caches./
>
> //
>
> We might include this fix in the last [1]. WDYT, can we proceed with [1]
> then ?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12779
>
>
>
> 02.04.2020 19:58, Вячеслав Коптилин пишет:
> > Hi Vladimir,
> >
> >> There are about 15 places in inner logic with this description.
> >> I propose balance between code base size and comment completeness.
> > I agree with Iva and I also think that this approach is not so good.
> > Perhaps we can add just a link to the one method which will provide a
> > comprehensive description, something like as follows
> > @param forceDeactivation {@code true} if cluster deactivation should be
> > forced. Please take a look at {@link IgniteCluster#state(ClusterState
> > newState, boolean force)} for the details.
> >
> > What do you think?
> >
> > Thanks,
> > Slava.
> >
> > чт, 2 апр. 2020 г. в 18:47, Vladimir Steshin :
> >
> >> Ivan, hello.
> >>
> >> Thanks. I vote for keeping the comments as they are now :)
> >>
> >> Igniters, it seems we are agreed to merge [1]. And the ticked s to be
> >> reverted in future with new designed solution of keeping in-memory data
> >> after deactivation.
> >>
> >> Right?
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-12779
> >>
> >>
> >> 01.04.2020 20:20, Ivan Rakov пишет:
> >>> I don't think that making javadocs more descriptive can be considered
> as
> >>> harmful code base enlargement.
> >>> I'd recommend to extend the docs, but the last word is yours ;)
> >>>
> >>> On Tue, Mar 31, 2020 at 2:44 PM Vladimir Steshin
> >> wrote:
> >>>> Ivan, hi.
> >>>>
> >>>> I absolutely agree this particular description is not enough to see
> the
> >>>> deactivation issue. I also vote for brief code.
> >>>>
> >>>> There are about 15 places in inner logic with this description. I
> >>>> propose balance between code base size and comment completeness.
> >>>>
> >>>> Should we enlarge code even if we got several full descriptions?
> >>>>
> >>>>
> >>>> 30.03.2020 20:02, Ivan Rakov пишет:
> >>>>> Vladimir,
> >>>>>
> >>>>> @param forceDeactivation If {@code true}, cluster deactivation will
> be
> >>>>>> forced.
> >>>>> It's true that it's possible to infer semantics of forced
> deactivation
> >>>> from
> >>>>> other parts of API. I just wanted to highlight that exactly this
> >>>>> description explains something that can be guessed by the parameter
> >> name.
> >>>>> I suppose to shorten the lookup path and shed a light on deactivation
> >>>>> semantics a bit:
> >>>>>
> >>>>>> @param forceDeactivation If {@code true}, cluster will be
> deactivated
> >>>> even
> >>>>>> if running in-memory caches are present. All data in the
> corresponding
> >>>>>> caches will be vanished as a result.
> >>>>> Does this make sense?
> >>>>>
> >>>>> On Fri, Mar 27, 2020 at 12:00 PM Vladimir Steshin <
> vlads...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Ivan, hi.
> >>>>>>
> >>>>>>
> >>>>>> 1) >>> Is it correct? If we are on the same page, let's proceed this
> >>
Re: Data vanished from cluster after INACTIVE/ACTIVE switch
fully rollback* [1] and [2] once cache data survival
> after
> >>>>> activation-deactivation cycle will be implemented.
> >>>>>
> >>>>> Is it correct? If we are on the same page, let's proceed this way.
> >>>>> I propose to:
> >>>>> - Create a JIRA issue for in-memory-data-safe deactivation (possibly,
> >>>>> without IEP and detailed design so far)
> >>>>> - Describe in the issue description what exact parts of API should be
> >>>>> removed under the issue scope.
> >>>>>
> >>>>> Also, a few questions on already merged [1]:
> >>>>> - We have removed GridClientClusterState#state(ClusterState) from
> Java
> >>>>> client API. Is it a legitimate thing to do? Don't we have to support
> >> API
> >>>>> compatibility for thin clients as well?
> >>>>> - In many places in the code I can see the following javadoc
> >>>>>
> >>>>>> @param forceDeactivation If {@code true}, cluster deactivation
> will
> >>>> be forced.
> >>>>>> As for me, this javadoc doesn't clarify anything. I'd suggest to
> >>>> describe
> >>>>> in which cases deactivation won't happen unless it's forced and which
> >>>>> impact forced deactivation will bring on the system.
> >>>>>
> >>>>> [1]: https://issues.apache.org/jira/browse/IGNITE-12701
> >>>>> [2]: https://issues.apache.org/jira/browse/IGNITE-12779
> >>>>> [3]: https://issues.apache.org/jira/browse/IGNITE-12614
> >>>>>
> >>>>> --
> >>>>> Ivan
> >>>>>
> >>>>> On Tue, Mar 24, 2020 at 7:18 PM Vladimir Steshin >
> >>>> wrote:
> >>>>>> Hi, Igniters.
> >>>>>>
> >>>>>> I'd like to remind you that cluster can be deactivated by user with
> 3
> >>>>>> utilities: control.sh, *JMX and the REST*. Proposed in [1] solution
> is
> >>>>>> not about control.sh. It suggests same approach regardless of the
> >>>>>> utility user executes. The task touches *only* *API of the user
> >> calls*,
> >>>>>> not the internal APIs.
> >>>>>>
> >>>>>> The reasons why flag “--yes” and confirmation prompt hasn’t taken
> into
> >>>>>> account for control.sh are:
> >>>>>>
> >>>>>> -Various commands widely use “--yes” just to start. Even not
> dangerous
> >>>>>> ones require “--yes” to begin. “--force” is dedicated for *harmless
> >>>>>> actions*.
> >>>>>>
> >>>>>> -Checking of probable data erasure works after command start and
> >>>>>> “--force” may not be required at all.
> >>>>>>
> >>>>>> -There are also JMX and REST. They have no “—yes” but should work
> >> alike.
> >>>>>> To get the deactivation safe I propose to merge last ticket
> >> with
> >>>>>> the JMX fixes [2]. In future releases, I believe, we should estimate
> >>>>>> jobs and fix memory erasure in general. For now, let’s prevent it.
> >> WDYT?
> >>>>>>
> >>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12614
> >>>>>>
> >>>>>> [2] https://issues.apache.org/jira/browse/IGNITE-12779
> >>>>>>
> >>>>>>
> >>>>>> 24.03.2020 15:55, Вячеслав Коптилин пишет:
> >>>>>>> Hello Nikolay,
> >>>>>>>
> >>>>>>> I am talking about the interactive mode of the control utility,
> which
> >>>>>>> requires explicit confirmation from the user.
> >>>>>>> Please take a look at DeactivateCommand#prepareConfirmation and its
> >>>>>> usages.
> >>>>>>> It seems to me, this mode has the same aim as the forceDeactivation
> >>>> flag.
> >>>>>>> We can change the message returned by
> >>>>>> DeactivateCommand#confirmationPrompt
> >>>>>>> as follows:
> >>>>>>> "Warning: the command will deactivate the cluster nnn and
> >> clear
> >>>>>>> in-memory cac
