Re: IGNITE-12361 Migrate Flume module to ignite-extensions
Hi, I have updated the PR as per review feedback. Please take a look and share your feedback. Regards, Saikat On Sat, Mar 7, 2020 at 2:08 PM Saikat Maitra wrote: > Hi Evgenii, > > I have responded to your questions and comments. > > Please take a look and share your thoughts. > > Regards, > Saikat > > > On Wed, Feb 12, 2020 at 7:04 PM Evgenii Zhuravlev < > e.zhuravlev...@gmail.com> wrote: > >> Hi Saikat, >> >> I left a couple of comments in pr: >> >> https://github.com/apache/ignite-extensions/pull/4#pullrequestreview-357891629 >> . >> Please tell me what do you think about it. >> >> Best Regards, >> Evgenii >> >> вт, 11 февр. 2020 г. в 17:15, Saikat Maitra : >> >> > Hi, >> > >> > Can someone please help in review for these following PRs. I have >> > received approval for release process from Alexey and would need a code >> > review approval for following PR. >> > >> > Jira https://issues.apache.org/jira/browse/IGNITE-12361 >> > >> > PR https://github.com/apache/ignite-extensions/pull/4 >> > https://github.com/apache/ignite/pull/7227 >> > >> > Regards, >> > Saikat >> > >> > On Tue, Feb 11, 2020 at 6:47 PM Saikat Maitra >> > wrote: >> > >> > > Hi Alexey, >> > > >> > > >> > > I think we can release for spring boot autoconfigure module. >> > > >> > > Nikolay - Do you have tentative timeline when you are planning for >> > release >> > > of spring boot autoconfigure module. >> > > >> > > >> > > After that we are planning to make release for flink ext. >> > > >> > > >> > > Since, each module are independent so they will be released >> > independently. >> > > >> > > >> > > Regards, >> > > Saikat >> > > >> > > On Mon, 10 Feb 2020 at 7:33 AM, Alexey Goncharuk < >> > > alexey.goncha...@gmail.com> wrote: >> > > >> > >> Saikat, >> > >> >> > >> Yes, I think we can go ahead with the modules PRs as long as >> reviewers >> > are >> > >> ok with the changes. Given that there is an activity around the >> spring >> > >> module, which modules do you think will get to the first release? >> > >> >> > >> сб, 1 февр. 2020 г. в 21:37, Saikat Maitra > >: >> > >> >> > >> > Hi Alexey, >> > >> > >> > >> > Please let me know if I can share more info on the release >> process. I >> > >> have >> > >> > updated the issue confluence page on discussed approach for Ignite >> > >> > Extensions. Do you think the open PRs can be merged in Ignite >> > Extensions >> > >> > repo? >> > >> > >> > >> > Independent Integrations: >> > >> > >> > >> > >> > >> >> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations >> > >> > Discussion Links: >> > >> > >> > >> > >> > >> >> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-DiscussionLinks >> > >> > Tickets: >> > >> > >> > >> > >> > >> >> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-Tickets >> > >> > >> > >> > Regards, >> > >> > Saikat >> > >> > >> > >> > On Sun, Jan 26, 2020 at 3:11 PM Saikat Maitra < >> > saikat.mai...@gmail.com> >> > >> > wrote: >> > >> > >> > >> > > Hi Alexey, >> > >> > > >> > >> > > As discussed I have updated the wiki with agreed solution. >> > >> > > >> > >> > > Independent Integrations: >> > >> > > >> > >> > >> > >> >> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations >> > >> > > >> > >> > > Discussion Links: >> > >> > > >> > >> > >> > >> >> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-DiscussionLinks >> > >> > > >> > >> > > Tickets: >> > >> > > >> > >> > >> > >> >> > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-Tickets >> > >> > > >> > >> > > Please let me know if I can share more information. >> > >> > > >> > >> > > Regards, >> > >> > > Saikat >> > >> > > >> > >> > > >> > >> > > On Fri, Jan 17, 2020 at 9:16 PM Saikat Maitra < >> > >> saikat.mai...@gmail.com> >> > >> > > wrote: >> > >> > > >> > >> > >> Hello Alexey, >> > >> > >> >> > >> > >> Thank you for your email. >> > >> > >> >> > >> > >> 1. Yes, we discussed in dev list and agreed on creating a new >> > >> repository >> > >> > >> for hosting our Ignite integrations. Please find the discussion >> > >> thread >> > >> > >> below. I will update the wiki page as well and share updates. >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> > >> >> > >> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Proposal-for-Ignite-Extensions-as-a-separate-Bahir-module-or-Incubator-project-td44064.html >> > >> > >> >> > >> > >> 2. I was hoping to complete migration of the following modules >> > >> before we >> > >> > >> go ahead with release. I am tracking the jira story here >> > >> > >> https://issues.apache.org/jira/browse/IGNITE-12355 >> > >> > >> >> > >> > >>- Flink >> > >> > >>- Twitter >> > >> > >>- Storm >> > >> > >>- ZeroMQ >>
Re: IGNITE-12358 Migrate ZeroMQ module to ignite-extensions
Hello, I wanted to discuss on merge process for PR in ignite modules when we are migrating extensions. I have created these 2 PR for ZeroMQ to migrate from ignite to ignite extension repo and also to remove ZeroMQ from ignite repo. https://github.com/apache/ignite-extensions/pull/5 https://github.com/apache/ignite/pull/7240 Both the PR are reviewed and in approved state and I have merged the changes for ignite-extensions. I wanted to discuss if this is right time to merge removal of ZeroMQ module PR from ignite repo or shall I wait for initial release of ignite-extensions - ZeroMQ module? Regards, Saikat On Fri, Mar 27, 2020 at 6:11 PM Saikat Maitra wrote: > Hi Mikhail, > > Thank you for help in review. I have merged the changes. > > Regards, > Saikat > > On Sun, Mar 8, 2020 at 1:39 PM Saikat Maitra > wrote: > >> Hi Ilya, Mikhail >> >> I have updated the PR as per review comments. >> >> Please take a look and share your feedback. >> >> PR https://github.com/apache/ignite-extensions/pull/5 >> https://github.com/apache/ignite/pull/7240 >> >> Regards, >> Saikat >> >> >> On Tue, Feb 11, 2020 at 7:17 PM Saikat Maitra >> wrote: >> >>> Hello, >>> >>> Can someone please help in review for these following PRs. I have >>> received approval for release process from Alexey and would need a code >>> review approval for following PR. >>> >>> Jira https://issues.apache.org/jira/browse/IGNITE-12358 >>> >>> PR https://github.com/apache/ignite-extensions/pull/5 >>> https://github.com/apache/ignite/pull/7240 >>> >>> >>> Regards, >>> Saikat >>> >>> On Fri, Jan 17, 2020 at 8:38 PM Saikat Maitra >>> wrote: >>> Yes sure, thank you Denis Regards, Saikat On Thu, Jan 16, 2020 at 3:53 PM Denis Magda wrote: > Hi Saikat, > > Let's wait while Alex Goncharuk checks a similar PR here: > > http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html > > After that, we can return to this pending pull request. > > - > Denis > > > On Sun, Jan 12, 2020 at 12:59 PM Saikat Maitra < > saikat.mai...@gmail.com> > wrote: > > > Hi, > > > > I have raised PR for Ignite zeromq migration to Ignite Extensions > repo. > > > > Jira https://issues.apache.org/jira/browse/IGNITE-12358 > > > > PR https://github.com/apache/ignite-extensions/pull/5 > > https://github.com/apache/ignite/pull/7240 > > > > Please review and share feedback. > > > > This is part of our Modularization effort for Streamer modules > > > > https://issues.apache.org/jira/browse/IGNITE-12355 > > > > Regards, > > Saikat > > >
Re: IGNITE-12358 Migrate ZeroMQ module to ignite-extensions
Hi Mikhail, Thank you for help in review. I have merged the changes. Regards, Saikat On Sun, Mar 8, 2020 at 1:39 PM Saikat Maitra wrote: > Hi Ilya, Mikhail > > I have updated the PR as per review comments. > > Please take a look and share your feedback. > > PR https://github.com/apache/ignite-extensions/pull/5 > https://github.com/apache/ignite/pull/7240 > > Regards, > Saikat > > > On Tue, Feb 11, 2020 at 7:17 PM Saikat Maitra > wrote: > >> Hello, >> >> Can someone please help in review for these following PRs. I have >> received approval for release process from Alexey and would need a code >> review approval for following PR. >> >> Jira https://issues.apache.org/jira/browse/IGNITE-12358 >> >> PR https://github.com/apache/ignite-extensions/pull/5 >> https://github.com/apache/ignite/pull/7240 >> >> >> Regards, >> Saikat >> >> On Fri, Jan 17, 2020 at 8:38 PM Saikat Maitra >> wrote: >> >>> Yes sure, thank you Denis >>> >>> Regards, >>> Saikat >>> >>> On Thu, Jan 16, 2020 at 3:53 PM Denis Magda wrote: >>> Hi Saikat, Let's wait while Alex Goncharuk checks a similar PR here: http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html After that, we can return to this pending pull request. - Denis On Sun, Jan 12, 2020 at 12:59 PM Saikat Maitra >>> > wrote: > Hi, > > I have raised PR for Ignite zeromq migration to Ignite Extensions repo. > > Jira https://issues.apache.org/jira/browse/IGNITE-12358 > > PR https://github.com/apache/ignite-extensions/pull/5 > https://github.com/apache/ignite/pull/7240 > > Please review and share feedback. > > This is part of our Modularization effort for Streamer modules > > https://issues.apache.org/jira/browse/IGNITE-12355 > > Regards, > Saikat > >>>
Do we have any Python experts in the community?
Igniters, Is any of you is skillful enough to contribute improvements to our Python thin client? For instance, that's one of the tickets that has been recently reported on the user list: https://issues.apache.org/jira/browse/IGNITE-12809 - Denis
Re: Change Ignite download.cgi page to satisfy requirements
Agreed, I'll ask INFRA to proceed with the Git migration first days next week. Please wait while the migration ends. - Denis On Fri, Mar 27, 2020 at 11:22 AM Maxim Muzafarov wrote: > Denis, > > I think we can move to git first. I'll do the changes discussed above > by the end of the next week. > > On Fri, 27 Mar 2020 at 20:55, Denis Magda wrote: > > > > Maxim, > > > > The new website is launched [1] and we can proceed with the changes > > discussed in this thread. > > > > Will you have time to implement those next week? If it's highly unlikely > > then I would request INFRA to move the website to Git first. > > > > [1] > > > http://apache-ignite-developers.2346864.n4.nabble.com/ANNOUNCEMENT-Ignite-New-Website-is-Live-td46730.html > > > > - > > Denis > > > > > > On Wed, Mar 25, 2020 at 9:47 AM Denis Magda wrote: > > > > > Hi Maxim, > > > > > > Here is a ticket [1] where I've collected INFRA recommendations shared > in > > > an adjacent discussion thread. Please check it, add anything new you > heard > > > from them. > > > > > > Feel free to take over this task, appreciate your help. However, please > > > give me a couple of days to finish the merge of the new website to the > > > master branch. After that, you can update the downloads page and I'll > > > request INFRA to move the website to a Git repository. I'll send a note > > > here once the new website is released. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12775 > > > > > > - > > > Denis > > > > > > > > > On Wed, Mar 25, 2020 at 3:31 AM Maxim Muzafarov > wrote: > > > > > >> Igniters, > > >> > > >> > > >> I've recently found that some of our releases were missed at the > > >> Apache announce mail list: 2.6.0 [4], 2.7.0 [5], 2.8.0 [3]. > > >> > > >> I've contacted the Apache announce list moderators and got the > > >> requirements for our download page [6] (see the message below). I'm > > >> going to update the download page on the Apache Ignite website > > >> according to received instructions using these pages as an example [1] > > >> [2]. > > >> > > >> WDYT? > > >> > > >> > > >> Denis, > > >> > > >> Do we have maintainer here or I can proceed with this by myself? > > >> > > >> > > >> > > > > >> > > >> Sorry, but the download page does not meet the requirements. > > >> > > >> 1) There is no link to the KEYS file > > >> https://downloads.apache.org/ignite/KEYS > > >> This is necessary for validating downloaded artifacts > > >> > > >> 2) No description of how to validate downloads > > >> > > >> 3) There is a link to nightly builds. > > >> That is not allowed on a public download page, as the builds have not > been > > >> voted on. > > >> > > >> 4) The paragraph introducing the binary artifact says: > > >> > > >> "In order to verify the release, we recommend that you download the > > >> official source distribution and verify the signatures of the > downloaded > > >> files before opening them." > > >> > > >> This does not make sense in the binary section (it belongs in the > source > > >> section and/or needs rewording). > > >> Nor is there any description of how to perform the verification. > > >> > > >> Please correct the page and resubmit the announce when that has been > done. > > >> > > >> < < > > >> > > >> [1] https://tika.apache.org/download.html > > >> [2] http://tomcat.apache.org/download-70.cgi > > >> [3] > > >> > http://mail-archives.us.apache.org/mod_mbox/www-announce/202003.mbox/browser > > >> [4] > > >> > http://mail-archives.us.apache.org/mod_mbox/www-announce/201806.mbox/browser > > >> [5] > > >> > http://mail-archives.us.apache.org/mod_mbox/www-announce/201812.mbox/browser > > >> [6] https://ignite.apache.org/download.cgi > > >> > > > >
Re: [ANNOUNCEMENT] Ignite New Website is Live
Pavel, Yes, I removed the page intentionally. None of us had any time to keep that list up-to-date. I don't think that it will bring any harm as long as Ignite developers will be googling for topics of interest and all our blogs (including yours) will pop up at the top of the search results (as long as they are published on highly-ranked resources). - Denis On Fri, Mar 27, 2020 at 11:56 AM Pavel Tupitsyn wrote: > Denis, this is awesome, thank you! > > There is no Blogs page anymore, is that intentional? > > On Fri, Mar 27, 2020 at 8:46 PM Denis Magda wrote: > >> Dear Community, >> >> I've just merged and released a new version of the website. Take your >> time and enjoy the new look & feel, structure, content, and navigation menu: >> https://ignite.apache.org >> >> Thanks to everyone who took part in the most recent Ignite survey [1] and >> helped us pinpoint key use cases of the projects. Those are now engraved on >> the front page to let new Ignite users figure out quicker our advantages. >> Thanks to all of you who took part in the new website review [2] sharing >> feedback publicly and privately. Finally, let me applaud to Mauricio and >> Ignacio who were in charge of the most heavyweight tasks and rebuilt the >> website from scratch using new design and structure. >> >> Send us a note if you catch any issues. The next step is to migrate the >> source code to Git... >> >> [1] >> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Evolution-Direction-short-questionary-td44577.html >> [2] >> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Website-New-Look-td46324.html >> >> - >> Denis >> >
Re: [ANNOUNCEMENT] Ignite New Website is Live
Denis, this is awesome, thank you! There is no Blogs page anymore, is that intentional? On Fri, Mar 27, 2020 at 8:46 PM Denis Magda wrote: > Dear Community, > > I've just merged and released a new version of the website. Take your time > and enjoy the new look & feel, structure, content, and navigation menu: > https://ignite.apache.org > > Thanks to everyone who took part in the most recent Ignite survey [1] and > helped us pinpoint key use cases of the projects. Those are now engraved on > the front page to let new Ignite users figure out quicker our advantages. > Thanks to all of you who took part in the new website review [2] sharing > feedback publicly and privately. Finally, let me applaud to Mauricio and > Ignacio who were in charge of the most heavyweight tasks and rebuilt the > website from scratch using new design and structure. > > Send us a note if you catch any issues. The next step is to migrate the > source code to Git... > > [1] > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Evolution-Direction-short-questionary-td44577.html > [2] > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Website-New-Look-td46324.html > > - > Denis >
Re: Change Ignite download.cgi page to satisfy requirements
Denis, I think we can move to git first. I'll do the changes discussed above by the end of the next week. On Fri, 27 Mar 2020 at 20:55, Denis Magda wrote: > > Maxim, > > The new website is launched [1] and we can proceed with the changes > discussed in this thread. > > Will you have time to implement those next week? If it's highly unlikely > then I would request INFRA to move the website to Git first. > > [1] > http://apache-ignite-developers.2346864.n4.nabble.com/ANNOUNCEMENT-Ignite-New-Website-is-Live-td46730.html > > - > Denis > > > On Wed, Mar 25, 2020 at 9:47 AM Denis Magda wrote: > > > Hi Maxim, > > > > Here is a ticket [1] where I've collected INFRA recommendations shared in > > an adjacent discussion thread. Please check it, add anything new you heard > > from them. > > > > Feel free to take over this task, appreciate your help. However, please > > give me a couple of days to finish the merge of the new website to the > > master branch. After that, you can update the downloads page and I'll > > request INFRA to move the website to a Git repository. I'll send a note > > here once the new website is released. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12775 > > > > - > > Denis > > > > > > On Wed, Mar 25, 2020 at 3:31 AM Maxim Muzafarov wrote: > > > >> Igniters, > >> > >> > >> I've recently found that some of our releases were missed at the > >> Apache announce mail list: 2.6.0 [4], 2.7.0 [5], 2.8.0 [3]. > >> > >> I've contacted the Apache announce list moderators and got the > >> requirements for our download page [6] (see the message below). I'm > >> going to update the download page on the Apache Ignite website > >> according to received instructions using these pages as an example [1] > >> [2]. > >> > >> WDYT? > >> > >> > >> Denis, > >> > >> Do we have maintainer here or I can proceed with this by myself? > >> > >> > >> > > > >> > >> Sorry, but the download page does not meet the requirements. > >> > >> 1) There is no link to the KEYS file > >> https://downloads.apache.org/ignite/KEYS > >> This is necessary for validating downloaded artifacts > >> > >> 2) No description of how to validate downloads > >> > >> 3) There is a link to nightly builds. > >> That is not allowed on a public download page, as the builds have not been > >> voted on. > >> > >> 4) The paragraph introducing the binary artifact says: > >> > >> "In order to verify the release, we recommend that you download the > >> official source distribution and verify the signatures of the downloaded > >> files before opening them." > >> > >> This does not make sense in the binary section (it belongs in the source > >> section and/or needs rewording). > >> Nor is there any description of how to perform the verification. > >> > >> Please correct the page and resubmit the announce when that has been done. > >> > >> < < > >> > >> [1] https://tika.apache.org/download.html > >> [2] http://tomcat.apache.org/download-70.cgi > >> [3] > >> http://mail-archives.us.apache.org/mod_mbox/www-announce/202003.mbox/browser > >> [4] > >> http://mail-archives.us.apache.org/mod_mbox/www-announce/201806.mbox/browser > >> [5] > >> http://mail-archives.us.apache.org/mod_mbox/www-announce/201812.mbox/browser > >> [6] https://ignite.apache.org/download.cgi > >> > >
Re: Change Ignite download.cgi page to satisfy requirements
Maxim, The new website is launched [1] and we can proceed with the changes discussed in this thread. Will you have time to implement those next week? If it's highly unlikely then I would request INFRA to move the website to Git first. [1] http://apache-ignite-developers.2346864.n4.nabble.com/ANNOUNCEMENT-Ignite-New-Website-is-Live-td46730.html - Denis On Wed, Mar 25, 2020 at 9:47 AM Denis Magda wrote: > Hi Maxim, > > Here is a ticket [1] where I've collected INFRA recommendations shared in > an adjacent discussion thread. Please check it, add anything new you heard > from them. > > Feel free to take over this task, appreciate your help. However, please > give me a couple of days to finish the merge of the new website to the > master branch. After that, you can update the downloads page and I'll > request INFRA to move the website to a Git repository. I'll send a note > here once the new website is released. > > [1] https://issues.apache.org/jira/browse/IGNITE-12775 > > - > Denis > > > On Wed, Mar 25, 2020 at 3:31 AM Maxim Muzafarov wrote: > >> Igniters, >> >> >> I've recently found that some of our releases were missed at the >> Apache announce mail list: 2.6.0 [4], 2.7.0 [5], 2.8.0 [3]. >> >> I've contacted the Apache announce list moderators and got the >> requirements for our download page [6] (see the message below). I'm >> going to update the download page on the Apache Ignite website >> according to received instructions using these pages as an example [1] >> [2]. >> >> WDYT? >> >> >> Denis, >> >> Do we have maintainer here or I can proceed with this by myself? >> >> >> > > >> >> Sorry, but the download page does not meet the requirements. >> >> 1) There is no link to the KEYS file >> https://downloads.apache.org/ignite/KEYS >> This is necessary for validating downloaded artifacts >> >> 2) No description of how to validate downloads >> >> 3) There is a link to nightly builds. >> That is not allowed on a public download page, as the builds have not been >> voted on. >> >> 4) The paragraph introducing the binary artifact says: >> >> "In order to verify the release, we recommend that you download the >> official source distribution and verify the signatures of the downloaded >> files before opening them." >> >> This does not make sense in the binary section (it belongs in the source >> section and/or needs rewording). >> Nor is there any description of how to perform the verification. >> >> Please correct the page and resubmit the announce when that has been done. >> >> < < >> >> [1] https://tika.apache.org/download.html >> [2] http://tomcat.apache.org/download-70.cgi >> [3] >> http://mail-archives.us.apache.org/mod_mbox/www-announce/202003.mbox/browser >> [4] >> http://mail-archives.us.apache.org/mod_mbox/www-announce/201806.mbox/browser >> [5] >> http://mail-archives.us.apache.org/mod_mbox/www-announce/201812.mbox/browser >> [6] https://ignite.apache.org/download.cgi >> >
[ANNOUNCEMENT] Ignite New Website is Live
Dear Community, I've just merged and released a new version of the website. Take your time and enjoy the new look & feel, structure, content, and navigation menu: https://ignite.apache.org Thanks to everyone who took part in the most recent Ignite survey [1] and helped us pinpoint key use cases of the projects. Those are now engraved on the front page to let new Ignite users figure out quicker our advantages. Thanks to all of you who took part in the new website review [2] sharing feedback publicly and privately. Finally, let me applaud to Mauricio and Ignacio who were in charge of the most heavyweight tasks and rebuilt the website from scratch using new design and structure. Send us a note if you catch any issues. The next step is to migrate the source code to Git... [1] http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Evolution-Direction-short-questionary-td44577.html [2] http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Website-New-Look-td46324.html - Denis
Re: Thin client: compute support
Agree with Igor, let's set deployment aside for now, it is out of scope of this IEP. On Fri, Mar 27, 2020 at 6:52 PM Igor Sapego wrote: > Hi guys, > > I like the proposal in general. > > Now for the task deployment - I think we should have separate API > for it (and separate IEP I believe). Also, I'm not sure that this API > should be a part of the API of any thin client as it seems weird to me > to use Python client to deploy Java tasks. Control.sh or visor proposal > sounds much better. > > Best Regards, > Igor > > > On Thu, Mar 26, 2020 at 10:56 PM Denis Magda wrote: > > > > > > > Deployment API definitely needed as one of the next steps. Currently, > we > > > are talking only about the first step (execution of already deployed > > > tasks). > > > Also, I'm not sure about automatic redeploy and peer-class-loading for > > thin > > > clients, I think it's better to have more control here and provide API > to > > > explicitly deploy classes or jar files. WDYT? > > > > > > Alex, agree that automatic redeployment is better suited for the > management > > APIs. How about adding this capability to our command-line tool > > (control.sh, or visor cmd, or one new holistic tool). > > > > - > > Denis > > > > > > On Wed, Mar 25, 2020 at 1:04 PM Alex Plehanov > > wrote: > > > > > Pavel, > > > > > > 1. Actually it can be solved on the client-side (and already solved in > > PoC > > > implementation). But I agreed it brings extra complexity for > client-side > > > implementation, will try to provide such guarantees on the server-side. > > > 2. ComputeTask has also "reduce" step which is executed on the > initiator > > > node. Binary-rest client implementation, for example, has such affinity > > > methods (to execute the task by name). I'm ok with removing it. At > least > > if > > > someone will need it we can implement it again at any time in the > future > > > without protocol change. > > > I've fixed IEP. > > > > > > Denis, > > > > > > Deployment API definitely needed as one of the next steps. Currently, > we > > > are talking only about the first step (execution of already deployed > > > tasks). > > > Also, I'm not sure about automatic redeploy and peer-class-loading for > > thin > > > clients, I think it's better to have more control here and provide API > to > > > explicitly deploy classes or jar files. WDYT? > > > > > > ср, 25 мар. 2020 г. в 21:17, Denis Magda : > > > > > > > Alex, thanks for preparing the outline. > > > > > > > > I'd like us to discuss an approach for compute tasks update with no > > > > downtimes on the servers' end. For instance, let's assume that a > > > > Python/C++/Node.JS developer requested to update a compute task he > > called > > > > from the app. Should we introduce some system level API to the binary > > > > protocol that can take a jar file (or class) and redeploy it > > > automatically > > > > with the usage of peer-class-loading? > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Wed, Mar 25, 2020 at 5:47 AM Alex Plehanov < > plehanov.a...@gmail.com > > > > > > > wrote: > > > > > > > > > Hello guys. > > > > > > > > > > I've implemented PoC and created IEP [1] for thin client compute > grid > > > > > functionality. Please have a look. > > > > > > > > > > [1]: > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-42+Thin+client%3A+compute+support > > > > > > > > > > пт, 24 янв. 2020 г. в 16:56, Alex Plehanov < > plehanov.a...@gmail.com > > >: > > > > > > > > > > > We've discussed thin client compute protocol with Pavel Tupitsyn > > and > > > > Igor > > > > > > Sapego and come to the conclusion that approach with two-way > > requests > > > > > > should be used: client generates taskId and send a request to the > > > > server > > > > > to > > > > > > execute a task. The server responds that the request has been > > > accepted. > > > > > > After task has finished the server notifies the client (send a > > > request > > > > > > without waiting for a response). The client can cancel the task > by > > > > > sending > > > > > > a corresponding request to the server. > > > > > > > > > > > > Also, a node list should be passed (optionally) with a request to > > > limit > > > > > > nodes to execute the task. > > > > > > > > > > > > I will create IEP and file detailed protocol changes shortly. > > > > > > > > > > > > вт, 21 янв. 2020 г. в 18:46, Alex Plehanov < > > plehanov.a...@gmail.com > > > >: > > > > > > > > > > > >> Igor, thanks for the reply. > > > > > >> > > > > > >> > Approach with taskId will require a lot of changes in protocol > > and > > > > > thus > > > > > >> more "heavy" for implementation > > > > > >> Do you mean approach with server notifications mechanism? Yes, > it > > > will > > > > > >> require a lot of changes. But in most recent messages we've > > > discussed > > > > > with > > > > > >> Pavel approach without server notifications mechanism. This > > approach > > > > > have > > > > > >> the same complexity and
Re: Thin client: compute support
Hi guys, I like the proposal in general. Now for the task deployment - I think we should have separate API for it (and separate IEP I believe). Also, I'm not sure that this API should be a part of the API of any thin client as it seems weird to me to use Python client to deploy Java tasks. Control.sh or visor proposal sounds much better. Best Regards, Igor On Thu, Mar 26, 2020 at 10:56 PM Denis Magda wrote: > > > > Deployment API definitely needed as one of the next steps. Currently, we > > are talking only about the first step (execution of already deployed > > tasks). > > Also, I'm not sure about automatic redeploy and peer-class-loading for > thin > > clients, I think it's better to have more control here and provide API to > > explicitly deploy classes or jar files. WDYT? > > > Alex, agree that automatic redeployment is better suited for the management > APIs. How about adding this capability to our command-line tool > (control.sh, or visor cmd, or one new holistic tool). > > - > Denis > > > On Wed, Mar 25, 2020 at 1:04 PM Alex Plehanov > wrote: > > > Pavel, > > > > 1. Actually it can be solved on the client-side (and already solved in > PoC > > implementation). But I agreed it brings extra complexity for client-side > > implementation, will try to provide such guarantees on the server-side. > > 2. ComputeTask has also "reduce" step which is executed on the initiator > > node. Binary-rest client implementation, for example, has such affinity > > methods (to execute the task by name). I'm ok with removing it. At least > if > > someone will need it we can implement it again at any time in the future > > without protocol change. > > I've fixed IEP. > > > > Denis, > > > > Deployment API definitely needed as one of the next steps. Currently, we > > are talking only about the first step (execution of already deployed > > tasks). > > Also, I'm not sure about automatic redeploy and peer-class-loading for > thin > > clients, I think it's better to have more control here and provide API to > > explicitly deploy classes or jar files. WDYT? > > > > ср, 25 мар. 2020 г. в 21:17, Denis Magda : > > > > > Alex, thanks for preparing the outline. > > > > > > I'd like us to discuss an approach for compute tasks update with no > > > downtimes on the servers' end. For instance, let's assume that a > > > Python/C++/Node.JS developer requested to update a compute task he > called > > > from the app. Should we introduce some system level API to the binary > > > protocol that can take a jar file (or class) and redeploy it > > automatically > > > with the usage of peer-class-loading? > > > > > > - > > > Denis > > > > > > > > > On Wed, Mar 25, 2020 at 5:47 AM Alex Plehanov > > > > wrote: > > > > > > > Hello guys. > > > > > > > > I've implemented PoC and created IEP [1] for thin client compute grid > > > > functionality. Please have a look. > > > > > > > > [1]: > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-42+Thin+client%3A+compute+support > > > > > > > > пт, 24 янв. 2020 г. в 16:56, Alex Plehanov >: > > > > > > > > > We've discussed thin client compute protocol with Pavel Tupitsyn > and > > > Igor > > > > > Sapego and come to the conclusion that approach with two-way > requests > > > > > should be used: client generates taskId and send a request to the > > > server > > > > to > > > > > execute a task. The server responds that the request has been > > accepted. > > > > > After task has finished the server notifies the client (send a > > request > > > > > without waiting for a response). The client can cancel the task by > > > > sending > > > > > a corresponding request to the server. > > > > > > > > > > Also, a node list should be passed (optionally) with a request to > > limit > > > > > nodes to execute the task. > > > > > > > > > > I will create IEP and file detailed protocol changes shortly. > > > > > > > > > > вт, 21 янв. 2020 г. в 18:46, Alex Plehanov < > plehanov.a...@gmail.com > > >: > > > > > > > > > >> Igor, thanks for the reply. > > > > >> > > > > >> > Approach with taskId will require a lot of changes in protocol > and > > > > thus > > > > >> more "heavy" for implementation > > > > >> Do you mean approach with server notifications mechanism? Yes, it > > will > > > > >> require a lot of changes. But in most recent messages we've > > discussed > > > > with > > > > >> Pavel approach without server notifications mechanism. This > approach > > > > have > > > > >> the same complexity and performance as an approach with requestId. > > > > >> > > > > >> > But such clients as Python, Node.js, PHP, Go most probably won't > > > have > > > > >> support for this API, at least for now. > > > > >> Without a server notifications mechanism, there will be no > breaking > > > > >> changes in the protocol, so client implementation can just skip > this > > > > >> feature and protocol version and implement the next one. > > > > >> > > > > >> > Or never. > > > > >> I think it still useful to
Re: Get rid of @Nullable and @NotNull
Folks, First of all, @NotNull already restricted. And cool guys should use asserts and explicit checks instead of checked-by-nobody annotations. Some contributors use vim to write the code, how will it check correctness? Or we should use only the IDEA? Second, >> I would consider every not annotated item as effectively @Nullable that's an absolutely correct statement! >> potential NPE places - where you forgot to check for null object marked @Nullable What's the difference between "@Nullable Object field" and just "Object field"? Correct, absolutely no difference. Both can be null. @Nullable annotation protects you from NPE even worse that Arbidol protects you from flu. On Fri, Mar 27, 2020 at 3:30 PM Dmitriy Pavlov wrote: > +1 for using @Nullable as it is a kind of documentation > +1 for using @NotNull as it protects from > wrong fields/variables assignments if modern IDE is used. > > пт, 27 мар. 2020 г. в 14:28, Sergey-A Kosarev : > > > Classification: Public > > > > +1 for using @Nullable. > > > > @Nullable is not panacea, but much better than nothing. > > > > It's clear indication that you should check the marked object for null > > before using. There is advantage in using @Nullable than @NotNull - Idea > or > > any tool like findbugs shows you potential NPE places - where you forgot > to > > check for null object marked @Nullable, otherwise if you use only > @NotNull > > it's much harder to see NPE problems as, I believe, always will be too > many > > noise - places where developers just forgot to place annotation. > > > > And another arguable point is statistics, in my experience there are more > > objects that not null by nature than nullable. So if you should mark only > > all @NotNull objects, you will need to place much more annotations than > if > > mark only @Nullable objects. > > > > Kind regards, > > Sergey Kosarev > > > > > > -Original Message- > > From: Ivan Pavlukhin [mailto:vololo...@gmail.com] > > Sent: 27 March 2020 13:28 > > To: dev > > Subject: Re: Get rid of @Nullable and @NotNull > > > > Here is my opinion. As we do not have a common practice to use @Nullable > > and @NotNull annotations everywhere I would consider every not annotated > > item as effectively @Nullable. @NotNull seems a useful annotation for me, > > sometimes it is a really good thing to assume that something cannot be > null > > instead of doing explicit null check everywhere. > > > > Best regards, > > Ivan Pavlukhin > > > > пт, 27 мар. 2020 г. в 13:05, Denis Garus : > > > > > > Hi! > > > I'm not sure that @Nullable can really fix the NPE problem. > > > Currently, we have @Nullable annotation and NPE simultaneously. > > > The best way to avoid NPE is by using a null object pattern. > > > I agree we shouldn't rely on @Nullable. > > > > > > > > > пт, 27 мар. 2020 г. в 12:58, Sergey Antonov >: > > > > > > > I disagree. > > > > > > > > Intellij idea IDE has a static code analysis, which uses that > > > > annotation too. IDE highlights possible problems. It helps to make > > > > our code more stable and bugless. > > > > > > > > пт, 27 мар. 2020 г. в 12:06, Pavel Tupitsyn : > > > > > > > > > I disagree, it would be a step back. > > > > > > > > > > > What's the reason for using it? > > > > > Null was a billion dollar mistake [1]. > > > > > NullPointerExceptions happen quite a lot in Ignite, and > > > > > annotations > > > > provide > > > > > some clues to avoid those. > > > > > > > > > > [1] > > > > > https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions > > > > > > > > > > On Fri, Mar 27, 2020 at 10:58 AM Anton Vinogradov > > wrote: > > > > > > > > > > > Folks, > > > > > > > > > > > > Found we still use @Nullable annotation. > > > > > > > > > > > > What's the reason for using it? > > > > > > Everything is Object and Nullable :) > > > > > > > > > > > > How about get rid of @Nullable usages and restrict its usage by > > > > > checkstyle > > > > > > plugin? > > > > > > > > > > > > BTW, We already "do not use @NotNull annotation" (с) Coding > > > > > > Guidelines > > > > > [1] > > > > > > which may have some cense in contrast to @Nullable. > > > > > > But I see a lot of usages at code. > > > > > > > > > > > > How about to get rid of @NotNull too and to add such check to > > > > checkstyle > > > > > > plugin too? > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines > > > > #CodingGuidelines-@Annotations > > > > > > > > > > > > > > > > > > > > > > > -- > > > > BR, Sergey Antonov > > > > > > > > > > --- > > This e-mail may contain confidential and/or privileged information. If > you > > are not the intended recipient (or have received this e-mail in error) > > please notify the sender immediately and delete this e-mail. Any > > unauthorized copying, disclosure or distribution of the material in this > > e-mail is strictly forbidden. > > > > Please refer to https://www.db.com/disclosures for additional EU > >
Re: Get rid of @Nullable and @NotNull
+1 for using @Nullable as it is a kind of documentation +1 for using @NotNull as it protects from wrong fields/variables assignments if modern IDE is used. пт, 27 мар. 2020 г. в 14:28, Sergey-A Kosarev : > Classification: Public > > +1 for using @Nullable. > > @Nullable is not panacea, but much better than nothing. > > It's clear indication that you should check the marked object for null > before using. There is advantage in using @Nullable than @NotNull - Idea or > any tool like findbugs shows you potential NPE places - where you forgot to > check for null object marked @Nullable, otherwise if you use only @NotNull > it's much harder to see NPE problems as, I believe, always will be too many > noise - places where developers just forgot to place annotation. > > And another arguable point is statistics, in my experience there are more > objects that not null by nature than nullable. So if you should mark only > all @NotNull objects, you will need to place much more annotations than if > mark only @Nullable objects. > > Kind regards, > Sergey Kosarev > > > -Original Message- > From: Ivan Pavlukhin [mailto:vololo...@gmail.com] > Sent: 27 March 2020 13:28 > To: dev > Subject: Re: Get rid of @Nullable and @NotNull > > Here is my opinion. As we do not have a common practice to use @Nullable > and @NotNull annotations everywhere I would consider every not annotated > item as effectively @Nullable. @NotNull seems a useful annotation for me, > sometimes it is a really good thing to assume that something cannot be null > instead of doing explicit null check everywhere. > > Best regards, > Ivan Pavlukhin > > пт, 27 мар. 2020 г. в 13:05, Denis Garus : > > > > Hi! > > I'm not sure that @Nullable can really fix the NPE problem. > > Currently, we have @Nullable annotation and NPE simultaneously. > > The best way to avoid NPE is by using a null object pattern. > > I agree we shouldn't rely on @Nullable. > > > > > > пт, 27 мар. 2020 г. в 12:58, Sergey Antonov : > > > > > I disagree. > > > > > > Intellij idea IDE has a static code analysis, which uses that > > > annotation too. IDE highlights possible problems. It helps to make > > > our code more stable and bugless. > > > > > > пт, 27 мар. 2020 г. в 12:06, Pavel Tupitsyn : > > > > > > > I disagree, it would be a step back. > > > > > > > > > What's the reason for using it? > > > > Null was a billion dollar mistake [1]. > > > > NullPointerExceptions happen quite a lot in Ignite, and > > > > annotations > > > provide > > > > some clues to avoid those. > > > > > > > > [1] > > > > https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions > > > > > > > > On Fri, Mar 27, 2020 at 10:58 AM Anton Vinogradov > wrote: > > > > > > > > > Folks, > > > > > > > > > > Found we still use @Nullable annotation. > > > > > > > > > > What's the reason for using it? > > > > > Everything is Object and Nullable :) > > > > > > > > > > How about get rid of @Nullable usages and restrict its usage by > > > > checkstyle > > > > > plugin? > > > > > > > > > > BTW, We already "do not use @NotNull annotation" (с) Coding > > > > > Guidelines > > > > [1] > > > > > which may have some cense in contrast to @Nullable. > > > > > But I see a lot of usages at code. > > > > > > > > > > How about to get rid of @NotNull too and to add such check to > > > checkstyle > > > > > plugin too? > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines > > > #CodingGuidelines-@Annotations > > > > > > > > > > > > > > > > > > -- > > > BR, Sergey Antonov > > > > > > --- > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and delete this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > Please refer to https://www.db.com/disclosures for additional EU > corporate and regulatory disclosures and to > http://www.db.com/unitedkingdom/content/privacy.htm for information about > privacy. >
RE: Get rid of @Nullable and @NotNull
Classification: Public +1 for using @Nullable. @Nullable is not panacea, but much better than nothing. It's clear indication that you should check the marked object for null before using. There is advantage in using @Nullable than @NotNull - Idea or any tool like findbugs shows you potential NPE places - where you forgot to check for null object marked @Nullable, otherwise if you use only @NotNull it's much harder to see NPE problems as, I believe, always will be too many noise - places where developers just forgot to place annotation. And another arguable point is statistics, in my experience there are more objects that not null by nature than nullable. So if you should mark only all @NotNull objects, you will need to place much more annotations than if mark only @Nullable objects. Kind regards, Sergey Kosarev -Original Message- From: Ivan Pavlukhin [mailto:vololo...@gmail.com] Sent: 27 March 2020 13:28 To: dev Subject: Re: Get rid of @Nullable and @NotNull Here is my opinion. As we do not have a common practice to use @Nullable and @NotNull annotations everywhere I would consider every not annotated item as effectively @Nullable. @NotNull seems a useful annotation for me, sometimes it is a really good thing to assume that something cannot be null instead of doing explicit null check everywhere. Best regards, Ivan Pavlukhin пт, 27 мар. 2020 г. в 13:05, Denis Garus : > > Hi! > I'm not sure that @Nullable can really fix the NPE problem. > Currently, we have @Nullable annotation and NPE simultaneously. > The best way to avoid NPE is by using a null object pattern. > I agree we shouldn't rely on @Nullable. > > > пт, 27 мар. 2020 г. в 12:58, Sergey Antonov : > > > I disagree. > > > > Intellij idea IDE has a static code analysis, which uses that > > annotation too. IDE highlights possible problems. It helps to make > > our code more stable and bugless. > > > > пт, 27 мар. 2020 г. в 12:06, Pavel Tupitsyn : > > > > > I disagree, it would be a step back. > > > > > > > What's the reason for using it? > > > Null was a billion dollar mistake [1]. > > > NullPointerExceptions happen quite a lot in Ignite, and > > > annotations > > provide > > > some clues to avoid those. > > > > > > [1] > > > https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions > > > > > > On Fri, Mar 27, 2020 at 10:58 AM Anton Vinogradov wrote: > > > > > > > Folks, > > > > > > > > Found we still use @Nullable annotation. > > > > > > > > What's the reason for using it? > > > > Everything is Object and Nullable :) > > > > > > > > How about get rid of @Nullable usages and restrict its usage by > > > checkstyle > > > > plugin? > > > > > > > > BTW, We already "do not use @NotNull annotation" (с) Coding > > > > Guidelines > > > [1] > > > > which may have some cense in contrast to @Nullable. > > > > But I see a lot of usages at code. > > > > > > > > How about to get rid of @NotNull too and to add such check to > > checkstyle > > > > plugin too? > > > > > > > > [1] > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines > > #CodingGuidelines-@Annotations > > > > > > > > > > > > > -- > > BR, Sergey Antonov > > --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
Re: Server Node comes down with : (err) Failed to notify listener: GridDhtTxPrepareFuture Error
>>As a temporary solution you can stop relying on peer class loading for continuous queries and provide the code of remote filters to the classpath of server nodes. Yes.. I was thinking of a solution on similar lines. Thank you for the reply. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-12843) TDE Phase-3. Cache key rotation.
Pavel Pereslegin created IGNITE-12843: - Summary: TDE Phase-3. Cache key rotation. Key: IGNITE-12843 URL: https://issues.apache.org/jira/browse/IGNITE-12843 Project: Ignite Issue Type: Sub-task Reporter: Pavel Pereslegin Assignee: Pavel Pereslegin Add the ability to rotate (change) the cache key. Design (draft): https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384 -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Get rid of @Nullable and @NotNull
Here is my opinion. As we do not have a common practice to use @Nullable and @NotNull annotations everywhere I would consider every not annotated item as effectively @Nullable. @NotNull seems a useful annotation for me, sometimes it is a really good thing to assume that something cannot be null instead of doing explicit null check everywhere. Best regards, Ivan Pavlukhin пт, 27 мар. 2020 г. в 13:05, Denis Garus : > > Hi! > I'm not sure that @Nullable can really fix the NPE problem. > Currently, we have @Nullable annotation and NPE simultaneously. > The best way to avoid NPE is by using a null object pattern. > I agree we shouldn't rely on @Nullable. > > > пт, 27 мар. 2020 г. в 12:58, Sergey Antonov : > > > I disagree. > > > > Intellij idea IDE has a static code analysis, which uses that > > annotation too. IDE highlights possible problems. It helps to make our code > > more stable and bugless. > > > > пт, 27 мар. 2020 г. в 12:06, Pavel Tupitsyn : > > > > > I disagree, it would be a step back. > > > > > > > What's the reason for using it? > > > Null was a billion dollar mistake [1]. > > > NullPointerExceptions happen quite a lot in Ignite, and annotations > > provide > > > some clues to avoid those. > > > > > > [1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions > > > > > > On Fri, Mar 27, 2020 at 10:58 AM Anton Vinogradov wrote: > > > > > > > Folks, > > > > > > > > Found we still use @Nullable annotation. > > > > > > > > What's the reason for using it? > > > > Everything is Object and Nullable :) > > > > > > > > How about get rid of @Nullable usages and restrict its usage by > > > checkstyle > > > > plugin? > > > > > > > > BTW, We already "do not use @NotNull annotation" (с) Coding Guidelines > > > [1] > > > > which may have some cense in contrast to @Nullable. > > > > But I see a lot of usages at code. > > > > > > > > How about to get rid of @NotNull too and to add such check to > > checkstyle > > > > plugin too? > > > > > > > > [1] > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-@Annotations > > > > > > > > > > > > > -- > > BR, Sergey Antonov > >
Re: Get rid of @Nullable and @NotNull
Hi! I'm not sure that @Nullable can really fix the NPE problem. Currently, we have @Nullable annotation and NPE simultaneously. The best way to avoid NPE is by using a null object pattern. I agree we shouldn't rely on @Nullable. пт, 27 мар. 2020 г. в 12:58, Sergey Antonov : > I disagree. > > Intellij idea IDE has a static code analysis, which uses that > annotation too. IDE highlights possible problems. It helps to make our code > more stable and bugless. > > пт, 27 мар. 2020 г. в 12:06, Pavel Tupitsyn : > > > I disagree, it would be a step back. > > > > > What's the reason for using it? > > Null was a billion dollar mistake [1]. > > NullPointerExceptions happen quite a lot in Ignite, and annotations > provide > > some clues to avoid those. > > > > [1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions > > > > On Fri, Mar 27, 2020 at 10:58 AM Anton Vinogradov wrote: > > > > > Folks, > > > > > > Found we still use @Nullable annotation. > > > > > > What's the reason for using it? > > > Everything is Object and Nullable :) > > > > > > How about get rid of @Nullable usages and restrict its usage by > > checkstyle > > > plugin? > > > > > > BTW, We already "do not use @NotNull annotation" (с) Coding Guidelines > > [1] > > > which may have some cense in contrast to @Nullable. > > > But I see a lot of usages at code. > > > > > > How about to get rid of @NotNull too and to add such check to > checkstyle > > > plugin too? > > > > > > [1] > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-@Annotations > > > > > > > > -- > BR, Sergey Antonov >
Re: Get rid of @Nullable and @NotNull
I disagree. Intellij idea IDE has a static code analysis, which uses that annotation too. IDE highlights possible problems. It helps to make our code more stable and bugless. пт, 27 мар. 2020 г. в 12:06, Pavel Tupitsyn : > I disagree, it would be a step back. > > > What's the reason for using it? > Null was a billion dollar mistake [1]. > NullPointerExceptions happen quite a lot in Ignite, and annotations provide > some clues to avoid those. > > [1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions > > On Fri, Mar 27, 2020 at 10:58 AM Anton Vinogradov wrote: > > > Folks, > > > > Found we still use @Nullable annotation. > > > > What's the reason for using it? > > Everything is Object and Nullable :) > > > > How about get rid of @Nullable usages and restrict its usage by > checkstyle > > plugin? > > > > BTW, We already "do not use @NotNull annotation" (с) Coding Guidelines > [1] > > which may have some cense in contrast to @Nullable. > > But I see a lot of usages at code. > > > > How about to get rid of @NotNull too and to add such check to checkstyle > > plugin too? > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-@Annotations > > > -- BR, Sergey Antonov
Re: Get rid of @Nullable and @NotNull
I disagree, it would be a step back. > What's the reason for using it? Null was a billion dollar mistake [1]. NullPointerExceptions happen quite a lot in Ignite, and annotations provide some clues to avoid those. [1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions On Fri, Mar 27, 2020 at 10:58 AM Anton Vinogradov wrote: > Folks, > > Found we still use @Nullable annotation. > > What's the reason for using it? > Everything is Object and Nullable :) > > How about get rid of @Nullable usages and restrict its usage by checkstyle > plugin? > > BTW, We already "do not use @NotNull annotation" (с) Coding Guidelines [1] > which may have some cense in contrast to @Nullable. > But I see a lot of usages at code. > > How about to get rid of @NotNull too and to add such check to checkstyle > plugin too? > > [1] > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-@Annotations >
Re: Data vanished from cluster after INACTIVE/ACTIVE switch
Ivan, hi.
1) >>> Is it correct? If we are on the same page, let's proceed this way
It is correct.
2) - In many places in the code I can see the following javadoc
@param forceDeactivation If {@code true}, cluster deactivation will be forced.
In the internal params/flags. You can also find /@see
ClusterState#INACTIVE/ and full description with several public APIs (
like /Ignite.active(boolean)/ ):
//
/* /
//
/* NOTE:/
//
/* Deactivation clears in-memory caches (without persistence) including
the system caches./
Should be enough. Is not?
27.03.2020 10:51, Ivan Rakov пишет:
Vladimir, Igniters,
Let's emphasize our final plan.
We are going to add --force flags that will be necessary to pass for a
deactivation if there are in-memory caches to:
1) Rest API (already implemented in [1])
2) Command line utility (already implemented in [1])
3) JMX bean (going to be implemented in [2])
We are *not* going to change IgniteCluster or any other thick Java API,
thus we are *not* going to merge [3].
We plan to *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 caches (without persistence) including system caches."
What do you think?
Thanks,
S.
вт, 24 мар. 2020 г. в 13:07, Nikolay Izhikov :
Hello, Slava.
Are you talking about this commit [1] (sorry for commit message it’s due
to the Github issue)?
The message for this command for now
«Deactivation stopped. Deactivation clears in-memory caches (without
persistence) including the system caches.»
Is it clear enough?
[1]
https://github.com/apache/ignite/commit/4921fcf1fecbd8a1ab02099e09cc2adb0b3ff88a
24 марта 2020 г., в 13:02, Вячеслав Коптилин
написал(а):
Hi Nikolay,
1. We should add —force flag to the command.sh deactivation command.
I just checked and it seems that the deactivation command
(control-utility.sh) already has a confirmation option.
Perhaps, we need to clearly state the consequences of using this
command
with in-memory caches.
Thanks,
S.
вт, 24 мар. 2020 г. в 12:51, Nikolay Izhikov :
Hello, Alexey.
I just repeat our agreement to be on the same page
The confirmation should only present in the user-facing interfaces.
1. We should add —force flag to the command.sh deactivation command.
2. We should throw the exception if
Re: Data vanished from cluster after INACTIVE/ACTIVE switch
Hello, Ivan.
> Is it correct? If we are on the same page, let's proceed this way.
+1 from me for your plan.
> We have removed GridClientClusterState#state(ClusterState) from Java client
> API. Is it a legitimate thing to do? Don't we have to support API
There is no changes in Public API except discussed in this thread.
GridClientClusterState is in internal package so it’s an internal class.
org/apache/ignite/internal/client/GridClientClusterState.java
> 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.
OK for me.
Feel free to suggest your statement.
> 27 марта 2020 г., в 10:51, Ivan Rakov написал(а):
>
> Vladimir, Igniters,
>
> Let's emphasize our final plan.
>
> We are going to add --force flags that will be necessary to pass for a
> deactivation if there are in-memory caches to:
> 1) Rest API (already implemented in [1])
> 2) Command line utility (already implemented in [1])
> 3) JMX bean (going to be implemented in [2])
> We are *not* going to change IgniteCluster or any other thick Java API,
> thus we are *not* going to merge [3].
> We plan to *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 caches (without persistence) including system caches."
>>>
>>> What do you think?
>>>
>>> Thanks,
>>> S.
>>>
>>> вт, 24 мар. 2020 г. в 13:07, Nikolay Izhikov :
>>>
Hello, Slava.
Are you talking about this commit [1] (sorry for commit message it’s due
to the Github issue)?
The message for this command for now
«Deactivation stopped. Deactivation clears in-memory caches (without
persistence) including the system caches.»
Is it clear enough?
[1]
>> https://github.com/apache/ignite/commit/4921fcf1fecbd8a1ab02099e09cc2adb0b3ff88a
> 24 марта 2020 г., в 13:02, Вячеслав Коптилин >>
написал(а):
> Hi Nikolay,
>
>> 1. We should add —force flag to the command.sh deactivation command.
> I just checked and it seems that the
Re: Security Subject of thin client on remote nodes
Denis, In general, code changes look good to me. If we decide to keep security API in its current state for a while, I highly recommend to extend its documentation. We don't have descriptive javadocs or articles about security API so far, so I expect that next contributors will face difficulties in untangling security logic. Let's help them a bit. See more details in my JIRA comment: https://issues.apache.org/jira/browse/IGNITE-12759 On Thu, Mar 26, 2020 at 5:54 PM Ivan Rakov wrote: > Denis, > > I'll review your PR. If this issue is a subject to be included in 2.8.1 in > emergency mode, I'm ok with the current API changes. > Please think about driving creating IEP on security API overhaul prior to > 2.9. I believe that you are the most suitable Ignite community member to > drive this activity. I'd love to share some ideas as well. > > On Tue, Mar 24, 2020 at 2:04 PM Denis Garus wrote: > >> Hi, guys! >> >> >> I agree that we should rework the security API, but it can take a long >> time. >> >> And currently, our users have certain impediments that are blockers for >> their job. >> >> I think we have to fix bugs that IEP-41 [1] contains as soon as possible >> to >> support our users. >> >> From my point of view, IEP-41 is the best place to track bug fixing. >> >> >> >>1. >> >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-41%3A+Security+Context+of+thin+client+on+remote+nodes >> >> >> вт, 24 мар. 2020 г. в 12:26, Ivan Rakov : >> >> > Alexey, >> > >> > That can be another version of our plan. If everyone agrees that >> > SecurityContext and SecuritySubject should be merged, such fix of thin >> > clients' issue will bring us closer to the final solution. >> > Denis, what do you think? >> > >> > On Tue, Mar 24, 2020 at 10:38 AM Alexei Scherbakov < >> > alexey.scherbak...@gmail.com> wrote: >> > >> > > Why can't we start gradually changing security API right now ? >> > > I see no point in delaying with. >> > > All changes will go to next 2.9 release anyway. >> > > >> > > My proposal: >> > > 1. Get rid of security context. Doing this will bring security API to >> > more >> > > or less consistent state. >> > > 2. Remove IEP-41 because it's no longer needed because of change [1] >> > > 3. Propose an IEP to make security API avoid using internals. >> > > >> > > >> > > >> > > пн, 23 мар. 2020 г. в 19:53, Denis Garus : >> > > >> > > > Hello, Alexei, Ivan! >> > > > >> > > > >> Seems like security API is indeed a bit over-engineered >> > > > >> > > > Nobody has doubt we should do a reworking of GridSecurityProcessor. >> > > > But this point is outside of scope thin client's problem that we are >> > > > solving. >> > > > I think we can create new IEP that will accumulate all ideas of >> > Ignite's >> > > > security improvements. >> > > > >> > > > >> Presence of the separate #securityContext(UUID) highlights that >> user >> > > > indeed should care >> > > > >> about propagation of thin clients' contexts between the cluster >> > nodes. >> > > > >> > > > I agree with Ivan. I've implemented both variants, >> > > > and I like one with #securityContext(UUID) more. >> > > > >> > > > Could you please take a look at PR [1] for the issue [2]? >> > > > >> > > > 1. https://github.com/apache/ignite/pull/7523 >> > > > 2. https://issues.apache.org/jira/browse/IGNITE-12759 >> > > > >> > > > пн, 23 мар. 2020 г. в 11:45, Ivan Rakov : >> > > > >> > > > > Alex, Denis, >> > > > > >> > > > > Seems like security API is indeed a bit over-engineered. >> > > > > >> > > > > Let's get rid of SecurityContext and use SecuritySubject instead. >> > > > > > SecurityContext is just a POJO wrapper over >> > > > > > SecuritySubject's >> > > > > > org.apache.ignite.plugin.security.SecuritySubject#permissions. >> > > > > > It's functionality can be easily moved to SecuritySubject. >> > > > > >> > > > > I totally agree. Both subject and context are implemented by >> plugin >> > > > > provider, and I don't see any reason to keep both abstractions, >> > > > especially >> > > > > if we are going to get rid of transferring subject in node >> attributes >> > > > > (argument that subject is more lightweight won't work anymore). >> > > > > >> > > > > Also, there's kind of mess in node authentication logic. There >> are at >> > > > least >> > > > > two components responsible for it: DiscoverySpiNodeAuthenticator >> > (which >> > > > is >> > > > > forcibly set by GridDiscoveryManager, but in fact public) and >> > > > > GridSecurityProcessor (which performs actual node auth logic, but >> > > > private). >> > > > > I also don't understand why we need both >> > > > > #authenticate(AuthenticationContext) and >> > #authenticateNode(ClusterNode, >> > > > > SecurityCredentials) methods while it's possible to set explicit >> > > > > SecuritySubjectType.REMOTE_NODE in AuthenticationContext (this is >> > > > arguable; >> > > > > perhaps there are strong reasons). >> > > > > >> > > > > Finally, areas of responsibility between IgniteSecurity and >> > > > >
Get rid of @Nullable and @NotNull
Folks, Found we still use @Nullable annotation. What's the reason for using it? Everything is Object and Nullable :) How about get rid of @Nullable usages and restrict its usage by checkstyle plugin? BTW, We already "do not use @NotNull annotation" (с) Coding Guidelines [1] which may have some cense in contrast to @Nullable. But I see a lot of usages at code. How about to get rid of @NotNull too and to add such check to checkstyle plugin too? [1] https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-@Annotations
Re: Data vanished from cluster after INACTIVE/ACTIVE switch
Vladimir, Igniters,
Let's emphasize our final plan.
We are going to add --force flags that will be necessary to pass for a
deactivation if there are in-memory caches to:
1) Rest API (already implemented in [1])
2) Command line utility (already implemented in [1])
3) JMX bean (going to be implemented in [2])
We are *not* going to change IgniteCluster or any other thick Java API,
thus we are *not* going to merge [3].
We plan to *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 caches (without persistence) including system caches."
> >
> > What do you think?
> >
> > Thanks,
> > S.
> >
> > вт, 24 мар. 2020 г. в 13:07, Nikolay Izhikov :
> >
> >> Hello, Slava.
> >>
> >> Are you talking about this commit [1] (sorry for commit message it’s due
> >> to the Github issue)?
> >>
> >> The message for this command for now
> >>
> >> «Deactivation stopped. Deactivation clears in-memory caches (without
> >> persistence) including the system caches.»
> >>
> >> Is it clear enough?
> >>
> >> [1]
> >>
> https://github.com/apache/ignite/commit/4921fcf1fecbd8a1ab02099e09cc2adb0b3ff88a
> >>
> >>
> >>> 24 марта 2020 г., в 13:02, Вячеслав Коптилин >
> >> написал(а):
> >>> Hi Nikolay,
> >>>
> 1. We should add —force flag to the command.sh deactivation command.
> >>> I just checked and it seems that the deactivation command
> >>> (control-utility.sh) already has a confirmation option.
> >>> Perhaps, we need to clearly state the consequences of using this
> command
> >>> with in-memory caches.
> >>>
> >>> Thanks,
> >>> S.
> >>>
> >>> вт, 24 мар. 2020 г. в 12:51, Nikolay Izhikov :
> >>>
> Hello, Alexey.
>
> I just repeat our agreement to be on the same page
>
> > The confirmation should only present in the user-facing interfaces.
> 1. We should add —force flag to the command.sh deactivation command.
> 2. We should throw the exception if cluster has in-memory caches and
> —force=false.
> 3. We shouldn’t change Java API for deactivation.
>
> Is it correct?
>
> > The DROP TABLE command does not have a "yes I am sure" clause in it
> I think it because the command itself has a «DROP» word in
