Re: Issue with custom security plugin and thin clients
Hello! I afraid these changes will not be included in the 2.10 version. сб, 19 дек. 2020 г. в 06:03, Vishwas Bm : > Hi Denis, > > Thanks for the feedback. > > I had also put a comment in one of your PR regarding iep-41. > https://github.com/apache/ignite/pull/8038#issuecomment-742230009 > > > It will be great if you can provide input on this. > > > Regards, > Vishwas > > On Fri, 18 Dec, 2020, 21:39 Denis Garus, wrote: > > > Hi! > > I don't understand why you do something related to thin clients inside > > onDisconnected method? > > The rest looks good to me. > > > > ср, 9 дек. 2020 г. в 17:00, vbm : > > > > > Hi Denis, > > > > > > Any thoughts on the approach mentioned above ? > > > > > > > > > Regards, > > > Vishwas > > > > > > > > > > > > -- > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > >
Re: [DISCUSSION] 3.0.0 Alpha release
Hi Val, That's the pace, I'll be happy to play with the alpha and share feedback. Also, what if we arrange a community gathering after the holidays to demonstrate what alpha does and get more details from the involved contributors on what's coming next? As for the release process, yes, that needs to be a formal vote as long as you're publishing artifacts to Maven and updating the website with references to the binaries and documentation pages. - Denis On Fri, Dec 18, 2020 at 6:13 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Igniters, > > The repository for Ignite 3.x [1] was created less than a month ago, and we > already have several merged pull requests. Many thanks to everyone involved > for the contributions! > > Currently, we have the following functionality available in the main > branch: > >- New configuration framework which is compatible with the HOCON format. >- The “ignite-runner” module, which currently incorporates the >aforementioned configuration framework and REST endpoints to interact > with >the framework. >- The first version of the unified CLI tool. > > This set of features does not include any actual Ignite APIs. However, it > clearly demonstrates the basic mechanics of how the product will be > installed and upgraded, how the user will interact with it, etc. I would > like to use this to gather feedback from the community in the early stages. > > To make sure the experience is as close to real life as possible, I want to > deliver what we have as an alpha release, meaning that all the required > binaries will be deployed on the website and in Maven. There will also be > some basic documentation describing how to install and use the product. > This way, anyone will be able to download the product and try it out. > > My main question here -- do we need a formal vote for such a build? Or it > can be treated as a release candidate? > > Any other thoughts? > > [1] https://github.com/apache/ignite-3 > > -Val >
Re: Issue with custom security plugin and thin clients
Hi Denis, Thanks for the feedback. I had also put a comment in one of your PR regarding iep-41. https://github.com/apache/ignite/pull/8038#issuecomment-742230009 It will be great if you can provide input on this. Regards, Vishwas On Fri, 18 Dec, 2020, 21:39 Denis Garus, wrote: > Hi! > I don't understand why you do something related to thin clients inside > onDisconnected method? > The rest looks good to me. > > ср, 9 дек. 2020 г. в 17:00, vbm : > > > Hi Denis, > > > > Any thoughts on the approach mentioned above ? > > > > > > Regards, > > Vishwas > > > > > > > > -- > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > >
Re: Query on ignite-kafka artifact (ignite-kafka-ext)
Hi Denis, Thanks for the reply. I will try to use the version of kafka-ext available in mvn repository with ignite master branch code. Regards, Vishwas On Sat, 19 Dec, 2020, 01:48 Denis Magda, wrote: > Hi Vishwas, > > Kafka and all other extensions I being moved to that separate repository > and will be released independently. We'll update and release new versions > of extensions whenever is needed. In the meantime, the Kafka extension > should be compatible with all Ignite version. So, just update your Maven > XML: > > https://ignite.apache.org/docs/latest/extensions-and-integrations/streaming/kafka-streamer#streaming-data-with-ignite-kafka-streamer-module > > - > Denis > > > On Thu, Dec 17, 2020 at 9:18 PM vbm wrote: > > > Hi, > > > > I had posted this question in user list, posting it here again. > > > > In 2.9.0 release of Ignite, ignite-kafka module was part of the ignite > git. > > Now when I check in master branch kafka module is not present, it has > been > > moved to https://github.com/apache/ignite-extensions > > > > Also in maven repository I see there is new artifact corresponding to > > ignite-extensions for kafka. > > > > org.apache.ignite > > ignite-kafka-ext > > 1.0.0 > > > > > > To which version of ignite is this compatible ? Can this be used with > > ignite > > 2.10.0 master branch ? > > When will the next release of ignite-kafka-ext be done ? Will it be done > > along with ignite release ? > > > > > > Regards, > > Vishwas > > > > > > > > -- > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > >
[DISCUSSION] 3.0.0 Alpha release
Igniters, The repository for Ignite 3.x [1] was created less than a month ago, and we already have several merged pull requests. Many thanks to everyone involved for the contributions! Currently, we have the following functionality available in the main branch: - New configuration framework which is compatible with the HOCON format. - The “ignite-runner” module, which currently incorporates the aforementioned configuration framework and REST endpoints to interact with the framework. - The first version of the unified CLI tool. This set of features does not include any actual Ignite APIs. However, it clearly demonstrates the basic mechanics of how the product will be installed and upgraded, how the user will interact with it, etc. I would like to use this to gather feedback from the community in the early stages. To make sure the experience is as close to real life as possible, I want to deliver what we have as an alpha release, meaning that all the required binaries will be deployed on the website and in Maven. There will also be some basic documentation describing how to install and use the product. This way, anyone will be able to download the product and try it out. My main question here -- do we need a formal vote for such a build? Or it can be treated as a release candidate? Any other thoughts? [1] https://github.com/apache/ignite-3 -Val
[GitHub] [ignite-3] asfgit closed pull request #4: IGNITE-13610 Initial version of unified CLI tool
asfgit closed pull request #4: URL: https://github.com/apache/ignite-3/pull/4 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [DISCUSS] Ignite 3.0 development approach
Hi Ivan, There was a very brief discussion around this. Basically, it looks like switching from Maven to something else is not going to bring much value, but at the same time will be quite demanding because the community has much more experience with Maven. However, I would say that it is still debatable at this point -- please feel free to share your thoughts on this. -Val On Thu, Dec 17, 2020 at 10:53 PM Ivan Pavlukhin wrote: > Hi Igniters, > > Forgive me that I am not reading dev list carefully these days. Was it > explicitly decided that Maven should be used as a build system for > Ignite 3? As there is a new repository we possibly can update our > build tools as well. What do you think? > > 2020-12-17 22:45 GMT+03:00, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > > Hi Dmitriy, > > > > I don't think there is any reason for concern at this point. The > community > > agreed on the scope of the changes for 3.0 - it is described on Wiki. The > > scope is quite big, so it is clear that 2.x and 3.x will have to exist in > > parallel for a significant amount of time, so we need a place where we > can > > merge the code for 3.x. Thus, I've created this new repo. We already have > > multiple IEPs, as well as several contributors who are actively involved > in > > development. Some of the first PRs were merged today. > > > > I didn't hear any objections since the repo was created. > > > > -Val > > > > On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov > wrote: > > > >> Folks, I'm a little bit concerned about the simultaneous > >> - existence of the repo https://github.com/apache/ignite-3 and PRs for > >> that > >> repo > >> - and a couple of downvotes from PMC members. > >> > >> Is it all fine here? Was there any vote /discussion where it was > >> discussed > >> and consensus approved? What is the status of the ignite-3 repo? > >> > >> вт, 15 дек. 2020 г. в 17:30, Carbone, Adam >: > >> > >> > I don't believe Java 7 was LTS, and I hope that others will have > >> > upgraded > >> > long before that. If that is the release timeframe for 3.0, then I > >> suppose > >> > that would makes sense, I would still doubt that people would be going > >> > newer than java 11, just my opinion of what I'm seeing. > >> > > >> > Regards > >> > ~adam > >> > > >> > Adam Carbone | Director of Innovation – Intelligent Platform Team | > >> > Bottomline Technologies > >> > Office: 603-501-6446 | Mobile: 603-570-8418 > >> > www.bottomline.com > >> > > >> > > >> > > >> > On 12/15/20, 4:25 AM, "Ilya Kasnacheev" > >> > wrote: > >> > > >> > Hello! > >> > > >> > I guess Ignite 3.0 will be ready for production use somewhere in > >> 2022, > >> > realistically. By that time, Java 8 will be long enough out of > >> support > >> > so > >> > that most companies will actually forbid its use, WRT > >> > vulnerabilities > >> > et > >> > all. > >> > > >> > After all we have managed to upgrade from Java 7 to Java 8 and > only > >> > got a > >> > minor amount of complaints. > >> > > >> > Regards, > >> > -- > >> > Ilya Kasnacheev > >> > > >> > > >> > пн, 14 дек. 2020 г. в 19:06, Carbone, Adam < > >> > adam.carb...@bottomline.com>: > >> > > >> > > So just one bit to consider... Are there features that you need > >> > to > >> > use in > >> > > these newer versions of java? Or are we just updating to stay > >> > current? The > >> > > reason I ask is that there are still lots of people in an > >> enterprise > >> > space > >> > > that are beholden to having to support legacy JAVAEE supported > >> > applications > >> > > on Websphere, Weblogic, Redhat, etc... and the organizations > that > >> > use those > >> > > platforms are slow to move... Most of them are still on Java8 > >> > > > >> > > So as a platform I think a strong consideration needs to be > >> > towards > >> > having > >> > > the broadest possible support profile until it becomes an > >> impediment > >> > to > >> > > doing things that the platform needs. So far I haven't seen huge > >> > things in > >> > > the newer versions of java that are must haves ( a few > exceptions > >> are > >> > > things that would be really nice to take advantage of ). > >> > > > >> > > I think that apache commons has taken the right approach by > >> > staying > >> > on > >> > > java 8 giving the largest possible user base. > >> > > > >> > > Even standardizing on java 11 would have to make us reconsider > >> > Ignite as > >> > > the platform we are using, we are not so invested in it as of > >> > now, > >> > even > >> > > though we have big plans to leverage it. Just because we aren't > >> sure > >> > when > >> > > we are going to be able to upgrade from java8. It has support > >> > through 2022, > >> > > so I imagine that is when we will be discussing that. > >> > > > >> > > Regards > >> > > > >> > > ~Adam > >> > > > >> > > Adam Carbone | Director of
Re: [DISCUSS] Notifications for ignite-3 repository
Folks, Can someone take a look at this PR? I'm generally OK with the change, but I'm not familiar with the mechanisms used here. -Val On Thu, Dec 17, 2020 at 11:16 PM Ivan Pavlukhin wrote: > Igniters, > > I noticed notifications about PRs in ignite-3 repository sent to > dev-list. I suppose we should configure notifications similar to main > ignite repository. I prepared a ticket [1] and PR for this. Please > review. > > [1] https://issues.apache.org/jira/browse/IGNITE-13875 > > -- > > Best regards, > Ivan Pavlukhin >
Re: Query on ignite-kafka artifact (ignite-kafka-ext)
Hi Vishwas, Kafka and all other extensions I being moved to that separate repository and will be released independently. We'll update and release new versions of extensions whenever is needed. In the meantime, the Kafka extension should be compatible with all Ignite version. So, just update your Maven XML: https://ignite.apache.org/docs/latest/extensions-and-integrations/streaming/kafka-streamer#streaming-data-with-ignite-kafka-streamer-module - Denis On Thu, Dec 17, 2020 at 9:18 PM vbm wrote: > Hi, > > I had posted this question in user list, posting it here again. > > In 2.9.0 release of Ignite, ignite-kafka module was part of the ignite git. > Now when I check in master branch kafka module is not present, it has been > moved to https://github.com/apache/ignite-extensions > > Also in maven repository I see there is new artifact corresponding to > ignite-extensions for kafka. > > org.apache.ignite > ignite-kafka-ext > 1.0.0 > > > To which version of ignite is this compatible ? Can this be used with > ignite > 2.10.0 master branch ? > When will the next release of ignite-kafka-ext be done ? Will it be done > along with ignite release ? > > > Regards, > Vishwas > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
[RESULT] [VOTE] Release Apache Ignite 2.9.1 (RC1)
Hello, Igniters! Apache Ignite 2.9.1 release (RC1) has been accepted. 6 "+1" votes received. Here are the votes received (in order received): - Pavel Tupitsyn (binding) - Ilya Kasnacheev (binding) - Nikolay Izhikov (binding) - Denis Magda (binding) - Alex Plehanov (binding) - Maxim Muzafarov (binding) Here is the link to the voting thread - http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-9-1-RC1-td50653.html Thank you!
[MTCGA]: new failures in builds [5795089] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New Critical Failure in master-nightly MVCC Cache 7 https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_MvccCache7?branch=%3Cdefault%3E Changes may lead to failure were done by - kirill tkalenko https://ci.ignite.apache.org/viewModification.html?modId=912316 - kirill tkalenko https://ci.ignite.apache.org/viewModification.html?modId=912326 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 21:52:30 18-12-2020
Re: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Maxim, Presently, there are 70 documentation tickets. Probably, these are all the tickets that we are moving from a release to a release. Could you help to prepare a list of 2.10-specific tickets (features, enhancements, required updates due to a change in the behavior)? As before, we can track these important 2.10-specific tickets under the "Documentation tasks for important tasks" features: https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.10#ApacheIgnite2.10-Documentationtasksforimportantfeatures - Denis On Fri, Dec 18, 2020 at 8:14 AM Maxim Muzafarov wrote: > Hello Nikita, > > Thanks for your support. > > You can find the 2.10 related documentation issues on the release wiki > page [1]. Currently, some of the important issues don't have the right > priorities, so it's better to sort them first. > > As for the time estimates, we've previously agreed that documentation > should be ready prior to the release voting date. You can find the > actual release dates here [2]. > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.10#ApacheIgnite2.10-Allunresolveddocumentationtasks > [2] > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.10#ApacheIgnite2.10-Releasephases > > On Fri, 18 Dec 2020 at 18:48, Никита Сафонов > wrote: > > > > Hi guys, > > > > I'd be more than happy to support the 2.10 release and contribute to the > > documentation. > > So could you please give me a scope of documentation tasks for 2.10 with > > the approximate time estimates? > > > > Regards, > > Nikita > > > > пн, 7 дек. 2020 г. в 16:23, Alexey Zinoviev : > > > > > Support it > > > > > > пн, 7 дек. 2020 г. в 14:03, Maxim Muzafarov : > > > > > > > Folks, > > > > > > > > > > > > I propose to shift a bit the release date since 2.9.1 has not > released > > > yet. > > > > > > > > > > > > Scope Freeze: December 28, 2020 > > > > Code Freeze: December 28, 2020 > > > > Voting Date: January 25, 2021 > > > > Release Date: February 1, 2021 > > > > > > > > WDYT? > > > > > > > > On Tue, 17 Nov 2020 at 12:59, Maxim Muzafarov > wrote: > > > > > > > > > > Folks, > > > > > > > > > > I've marked all the valuable features of 2.10 release with an > > > > > appropriate label. Please, let me know if I've missed anything. > > > > > > > > > > Here is the link to the JIRA: > > > > > https://s.apache.org/1hyfu > > > > > > > > > > > > > > > On Thu, 12 Nov 2020 at 12:28, Anton Vinogradov > wrote: > > > > > > > > > > > > > - Distributed environment tests [2] (Nikolay Izhikov, Anton > > > > > > > Vinogradov, Ivan Daschinskiy) > > > > > > > Will all related issues be included in the 2.10? > > > > > > We're at the final preparations phase. Going to start the merge > > > > discussion > > > > > > soon. > > > > > > > > > > > > On Wed, Nov 11, 2020 at 4:48 PM Alexey Zinoviev < > > > > zaleslaw@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Yes, Model Export/Import for ML will be finished, now it's > ready, > > > > but under > > > > > > > testing on my side. > > > > > > > > > > > > > > ср, 11 нояб. 2020 г. в 16:08, Nikolay Izhikov < > nizhi...@apache.org > > > >: > > > > > > > > > > > > > > > I suggest to include CDC feature to the 2.10 scope. > > > > > > > > > > > > > > > > > 11 нояб. 2020 г., в 16:06, Maxim Muzafarov < > mmu...@apache.org> > > > > > > > > написал(а): > > > > > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > > > > > > > > > > Can you clarify the issue statuses according to the Apache > > > Ignite > > > > > > > > > Roadmap [1] and the 2.10 Apache Ignite Release? Here are > some > > > > major > > > > > > > > > issues which are expected to be included in 2.10 with the > > > unknown > > > > > > > > > status: > > > > > > > > > > > > > > > > > > - Distributed environment tests [2] (Nikolay Izhikov, Anton > > > > > > > > > Vinogradov, Ivan Daschinskiy) > > > > > > > > > Will all related issues be included in the 2.10? > > > > > > > > > > > > > > > > > > - Native persistence defragmentation [6][7] (Anton > Kalashnikov, > > > > Sergey > > > > > > > > Chugunov) > > > > > > > > > Are we on the last mile with this for 2.10? > > > > > > > > > > > > > > > > > > - Consistency-related improvements for atomic caches [3] > > > (Alexey > > > > > > > > Scherbakov) > > > > > > > > > Do we have the JIRA issue? Will the issue be included in > 2.10? > > > > > > > > > > > > > > > > > > - Tombstone objects during rebalancing [4] (Alexey > Scherbakov) > > > > > > > > > The issue [4] is in progress state. Will it be finished > prior > > > to > > > > code > > > > > > > > freeze? > > > > > > > > > > > > > > > > > > - SQL runtime statistics (Konstantin Orlov) > > > > > > > > > Do we have an IEP for this or JIRA issue? > > > > > > > > > > > > > > > > > > - ML Model export/import [5] (Alexey Zinoviev) > > > > > > > > > - Will the issue be finished? > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > >
Re: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Hello Nikita, Thanks for your support. You can find the 2.10 related documentation issues on the release wiki page [1]. Currently, some of the important issues don't have the right priorities, so it's better to sort them first. As for the time estimates, we've previously agreed that documentation should be ready prior to the release voting date. You can find the actual release dates here [2]. [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.10#ApacheIgnite2.10-Allunresolveddocumentationtasks [2] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.10#ApacheIgnite2.10-Releasephases On Fri, 18 Dec 2020 at 18:48, Никита Сафонов wrote: > > Hi guys, > > I'd be more than happy to support the 2.10 release and contribute to the > documentation. > So could you please give me a scope of documentation tasks for 2.10 with > the approximate time estimates? > > Regards, > Nikita > > пн, 7 дек. 2020 г. в 16:23, Alexey Zinoviev : > > > Support it > > > > пн, 7 дек. 2020 г. в 14:03, Maxim Muzafarov : > > > > > Folks, > > > > > > > > > I propose to shift a bit the release date since 2.9.1 has not released > > yet. > > > > > > > > > Scope Freeze: December 28, 2020 > > > Code Freeze: December 28, 2020 > > > Voting Date: January 25, 2021 > > > Release Date: February 1, 2021 > > > > > > WDYT? > > > > > > On Tue, 17 Nov 2020 at 12:59, Maxim Muzafarov wrote: > > > > > > > > Folks, > > > > > > > > I've marked all the valuable features of 2.10 release with an > > > > appropriate label. Please, let me know if I've missed anything. > > > > > > > > Here is the link to the JIRA: > > > > https://s.apache.org/1hyfu > > > > > > > > > > > > On Thu, 12 Nov 2020 at 12:28, Anton Vinogradov wrote: > > > > > > > > > > > - Distributed environment tests [2] (Nikolay Izhikov, Anton > > > > > > Vinogradov, Ivan Daschinskiy) > > > > > > Will all related issues be included in the 2.10? > > > > > We're at the final preparations phase. Going to start the merge > > > discussion > > > > > soon. > > > > > > > > > > On Wed, Nov 11, 2020 at 4:48 PM Alexey Zinoviev < > > > zaleslaw@gmail.com> > > > > > wrote: > > > > > > > > > > > Yes, Model Export/Import for ML will be finished, now it's ready, > > > but under > > > > > > testing on my side. > > > > > > > > > > > > ср, 11 нояб. 2020 г. в 16:08, Nikolay Izhikov > >: > > > > > > > > > > > > > I suggest to include CDC feature to the 2.10 scope. > > > > > > > > > > > > > > > 11 нояб. 2020 г., в 16:06, Maxim Muzafarov > > > > > > > написал(а): > > > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > > > > > > > Can you clarify the issue statuses according to the Apache > > Ignite > > > > > > > > Roadmap [1] and the 2.10 Apache Ignite Release? Here are some > > > major > > > > > > > > issues which are expected to be included in 2.10 with the > > unknown > > > > > > > > status: > > > > > > > > > > > > > > > > - Distributed environment tests [2] (Nikolay Izhikov, Anton > > > > > > > > Vinogradov, Ivan Daschinskiy) > > > > > > > > Will all related issues be included in the 2.10? > > > > > > > > > > > > > > > > - Native persistence defragmentation [6][7] (Anton Kalashnikov, > > > Sergey > > > > > > > Chugunov) > > > > > > > > Are we on the last mile with this for 2.10? > > > > > > > > > > > > > > > > - Consistency-related improvements for atomic caches [3] > > (Alexey > > > > > > > Scherbakov) > > > > > > > > Do we have the JIRA issue? Will the issue be included in 2.10? > > > > > > > > > > > > > > > > - Tombstone objects during rebalancing [4] (Alexey Scherbakov) > > > > > > > > The issue [4] is in progress state. Will it be finished prior > > to > > > code > > > > > > > freeze? > > > > > > > > > > > > > > > > - SQL runtime statistics (Konstantin Orlov) > > > > > > > > Do we have an IEP for this or JIRA issue? > > > > > > > > > > > > > > > > - ML Model export/import [5] (Alexey Zinoviev) > > > > > > > > - Will the issue be finished? > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap > > > > > > > > [2] > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-56%3A+Distributed+environment+tests > > > > > > > > [3] > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-12+Make+ATOMIC+Caches+Consistent+Again > > > > > > > > [4] https://issues.apache.org/jira/browse/IGNITE-11704 > > > > > > > > [5] https://issues.apache.org/jira/browse/IGNITE-6642 > > > > > > > > [6] https://issues.apache.org/jira/browse/IGNITE-13143 > > > > > > > > [7] > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-47%3A+Native+persistence+defragmentation > > > > > > > > > > > > > > > > On Tue, 10 Nov 2020 at 15:58, Maxim Muzafarov < > > mmu...@apache.org > > > > > > > > > > wrote: > > > > > > > >> > > > > > > > >> Folks, > > > > > > > >> > > > > > > > >> I've created the
Re: Issue with custom security plugin and thin clients
Hi! I don't understand why you do something related to thin clients inside onDisconnected method? The rest looks good to me. ср, 9 дек. 2020 г. в 17:00, vbm : > Hi Denis, > > Any thoughts on the approach mentioned above ? > > > Regards, > Vishwas > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
Re: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Hi guys, I'd be more than happy to support the 2.10 release and contribute to the documentation. So could you please give me a scope of documentation tasks for 2.10 with the approximate time estimates? Regards, Nikita пн, 7 дек. 2020 г. в 16:23, Alexey Zinoviev : > Support it > > пн, 7 дек. 2020 г. в 14:03, Maxim Muzafarov : > > > Folks, > > > > > > I propose to shift a bit the release date since 2.9.1 has not released > yet. > > > > > > Scope Freeze: December 28, 2020 > > Code Freeze: December 28, 2020 > > Voting Date: January 25, 2021 > > Release Date: February 1, 2021 > > > > WDYT? > > > > On Tue, 17 Nov 2020 at 12:59, Maxim Muzafarov wrote: > > > > > > Folks, > > > > > > I've marked all the valuable features of 2.10 release with an > > > appropriate label. Please, let me know if I've missed anything. > > > > > > Here is the link to the JIRA: > > > https://s.apache.org/1hyfu > > > > > > > > > On Thu, 12 Nov 2020 at 12:28, Anton Vinogradov wrote: > > > > > > > > > - Distributed environment tests [2] (Nikolay Izhikov, Anton > > > > > Vinogradov, Ivan Daschinskiy) > > > > > Will all related issues be included in the 2.10? > > > > We're at the final preparations phase. Going to start the merge > > discussion > > > > soon. > > > > > > > > On Wed, Nov 11, 2020 at 4:48 PM Alexey Zinoviev < > > zaleslaw@gmail.com> > > > > wrote: > > > > > > > > > Yes, Model Export/Import for ML will be finished, now it's ready, > > but under > > > > > testing on my side. > > > > > > > > > > ср, 11 нояб. 2020 г. в 16:08, Nikolay Izhikov >: > > > > > > > > > > > I suggest to include CDC feature to the 2.10 scope. > > > > > > > > > > > > > 11 нояб. 2020 г., в 16:06, Maxim Muzafarov > > > > > > написал(а): > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > > > > Can you clarify the issue statuses according to the Apache > Ignite > > > > > > > Roadmap [1] and the 2.10 Apache Ignite Release? Here are some > > major > > > > > > > issues which are expected to be included in 2.10 with the > unknown > > > > > > > status: > > > > > > > > > > > > > > - Distributed environment tests [2] (Nikolay Izhikov, Anton > > > > > > > Vinogradov, Ivan Daschinskiy) > > > > > > > Will all related issues be included in the 2.10? > > > > > > > > > > > > > > - Native persistence defragmentation [6][7] (Anton Kalashnikov, > > Sergey > > > > > > Chugunov) > > > > > > > Are we on the last mile with this for 2.10? > > > > > > > > > > > > > > - Consistency-related improvements for atomic caches [3] > (Alexey > > > > > > Scherbakov) > > > > > > > Do we have the JIRA issue? Will the issue be included in 2.10? > > > > > > > > > > > > > > - Tombstone objects during rebalancing [4] (Alexey Scherbakov) > > > > > > > The issue [4] is in progress state. Will it be finished prior > to > > code > > > > > > freeze? > > > > > > > > > > > > > > - SQL runtime statistics (Konstantin Orlov) > > > > > > > Do we have an IEP for this or JIRA issue? > > > > > > > > > > > > > > - ML Model export/import [5] (Alexey Zinoviev) > > > > > > > - Will the issue be finished? > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap > > > > > > > [2] > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-56%3A+Distributed+environment+tests > > > > > > > [3] > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-12+Make+ATOMIC+Caches+Consistent+Again > > > > > > > [4] https://issues.apache.org/jira/browse/IGNITE-11704 > > > > > > > [5] https://issues.apache.org/jira/browse/IGNITE-6642 > > > > > > > [6] https://issues.apache.org/jira/browse/IGNITE-13143 > > > > > > > [7] > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-47%3A+Native+persistence+defragmentation > > > > > > > > > > > > > > On Tue, 10 Nov 2020 at 15:58, Maxim Muzafarov < > mmu...@apache.org > > > > > > > > wrote: > > > > > > >> > > > > > > >> Folks, > > > > > > >> > > > > > > >> I've created the release page on the Confluence. Feel free to > > mail in > > > > > > >> case of any errors. > > > > > > >> > > > > > > >> > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.10 > > > > > > >> > > > > > > >> On Fri, 6 Nov 2020 at 17:56, Maxim Muzafarov < > mmu...@apache.org > > > > > > > > wrote: > > > > > > >>> > > > > > > >>> Igniters, > > > > > > >>> > > > > > > >>> > > > > > > >>> Let's finalize the discussion [1] about the next upcoming > major > > > > > Apache > > > > > > >>> Ignite 2.10 release. The major improvements related to the > > proposed > > > > > > >>> release: > > > > > > >>> - Improvements for partition clearing related parts > > > > > > >>> - Add tracing of SQL queries. > > > > > > >>> - CPP: Implement Cluster API > > > > > > >>> - .NET: Thin client: Transactions > > > > > > >>> - .NET: Thin Client: Continuous Query > > > > > > >>> - Java Thin client Kubernetes discovery > > > > > > >>> > > > > > > >>>
Static hierarchy in jmx tree
Hello, everyone! Ignite has a changeable jmx hierarchy now. It may lead a lot of problems for product maintenance and monitoring: - By default where would be classloader that change every time that node has been restarted. It will lead to rediscover all metrics for node. - It's hard to create a single template for different deployments. For example we should have about 4 different templates for each combination of classLoader and instanceName. - It's hard for engineers to switch between different hierarchies. You have to recreate anything you already have. I've created https://issues.apache.org/jira/browse/IGNITE-12920 to change this behavior. I am going to: 1. Change IGNITE_MBEAN_APPEND_CLASS_LOADER_ID default value to false 2. Use instanceName in any case. If this option is set, the value will be used, otherwise use consistentId if it's null use nodeId 3. Add option IGNITE_MBEAN_APPEND_INSTANCE_NAME for backward compatibility. True by default 4. Update documentation according to changes What do you think? Igor
Limit amount of space available for Ignite persistence
Hi everyone! Ignite has a way to limit the amount of memory available to store information. If this limit is reached, then page eviction or page replacement will kick in and make sure that the amount occupied space stays in the configured limits. There are no such settings for the disk storage though. The ability to specify a limit for the data storage size would be convenient for the cases when you want to store historical data. Telling Ignite to store “as much as it fits to 200 GB” is more convenient than measuring the estimated rate of growth of the data storage size and setting up a time-based expiry, so that the historical data occupies no more than 200 GB. We already have a way to limit the amount of space occupied by WAL – by using DataStorageConfiguraion#maxWalArchiveSize. It would be nice to have a similar thing for the data itself. Can we implement something similar to the page eviction mechanism for the persistent data? Denis
[GitHub] [ignite-3] alievmirza commented on a change in pull request #4: IGNITE-13610 Initial version of unified CLI tool
alievmirza commented on a change in pull request #4:
URL: https://github.com/apache/ignite-3/pull/4#discussion_r545802730
##
File path:
modules/cli-demo/cli/src/main/java/org/apache/ignite/cli/IgniteCLIException.java
##
@@ -0,0 +1,30 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.ignite.cli;
+
+public class IgniteCLIException extends RuntimeException {
Review comment:
Somewhere you are using `*Cli*`, somewhere `*CLI*`, this should be
unified
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: Metastorage limitations
Nikolay, Thanks for your reply! I encountered a similar case to what you've described in point #1. I used a private plugin that writes some information to the metastorage. After that I decided to get rid of that plugin, while the information had already been written to the metastorage. Following the approach that you described and implemented in the PR, I'll need to work with the flag to ignore certain keys in the metastorage forever. That's quite inconvenient. Wouldn't it be better if we just limited the set of allowed types that can be stored in the metastorage? Instead of a POJO, a Map will be accepted. Denis On 18.12.2020, 13:59, "ткаленко кирилл" wrote: Hello everybody! If you look at the stackTrace, the error is that deserialized objects are being sent to listeners. It may be more correct to send a raw arrays of bytes, and each plugin will be able to process it if needed. 18.12.2020, 12:18, "Nikolay Izhikov" : > Hello, Denis. > > It’s a known issue for me. > Metastore is a private API, isn’t it? > AFAICU it can occur for two reasons: > > * User migrates from custom Ignite fork that has private improvements or plugins that write to the metastore. > * We have a blocker bug and just remove some internal class that can be written into metastore from distribution. > > I planned to fix it with some system flag. > During startup administrator just sets a list of the metastore items that should be ignored. > Please, take a look at the PR [1] > > WDYT? > >> it’s better to limit the metastorage with storing primitives only > > I think that ability to write object is very useful and should stay. > > [1] https://github.com/apache/ignite/pull/8221 > >> 18 дек. 2020 г., в 12:06, Mekhanikov Denis написал(а): >> >> Hi everyone! >> >> Ignite has a limitation that it can’t work with custom classes put into metastorage: https://issues.apache.org/jira/browse/IGNITE-13642 >> If you put a POJO into the metastorage, then Ignite will try to deserialize it using the classes it finds on the classpath. If it can’t do the deserialization, then the node will fail. >> >> There is an opinion that the metastorage wasn’t design for a case when classes that can disappear from Ignite distribution. >> If we follow this path, then it’s better to limit the metastorage with storing primitives only, so that it’s impossible to occasionally put anything breaking. >> If a piece of configuration is put into the metastorage by a plugin, then the plugin will be in charge of deserializing the configuration, and not Ignite. >> >> Alternatively we can try to fix the metastorage and make it ignore deserialization errors when they occur. >> >> What do you think? >> >> Denis
Re: Metastorage limitations
Hello everybody! If you look at the stackTrace, the error is that deserialized objects are being sent to listeners. It may be more correct to send a raw arrays of bytes, and each plugin will be able to process it if needed. 18.12.2020, 12:18, "Nikolay Izhikov" : > Hello, Denis. > > It’s a known issue for me. > Metastore is a private API, isn’t it? > AFAICU it can occur for two reasons: > > * User migrates from custom Ignite fork that has private improvements or > plugins that write to the metastore. > * We have a blocker bug and just remove some internal class that can be > written into metastore from distribution. > > I planned to fix it with some system flag. > During startup administrator just sets a list of the metastore items that > should be ignored. > Please, take a look at the PR [1] > > WDYT? > >> it’s better to limit the metastorage with storing primitives only > > I think that ability to write object is very useful and should stay. > > [1] https://github.com/apache/ignite/pull/8221 > >> 18 дек. 2020 г., в 12:06, Mekhanikov Denis >> написал(а): >> >> Hi everyone! >> >> Ignite has a limitation that it can’t work with custom classes put into >> metastorage: https://issues.apache.org/jira/browse/IGNITE-13642 >> If you put a POJO into the metastorage, then Ignite will try to deserialize >> it using the classes it finds on the classpath. If it can’t do the >> deserialization, then the node will fail. >> >> There is an opinion that the metastorage wasn’t design for a case when >> classes that can disappear from Ignite distribution. >> If we follow this path, then it’s better to limit the metastorage with >> storing primitives only, so that it’s impossible to occasionally put >> anything breaking. >> If a piece of configuration is put into the metastorage by a plugin, then >> the plugin will be in charge of deserializing the configuration, and not >> Ignite. >> >> Alternatively we can try to fix the metastorage and make it ignore >> deserialization errors when they occur. >> >> What do you think? >> >> Denis
[jira] [Created] (IGNITE-13876) Update documentation for 2.9.1 release
Yaroslav Molochkov created IGNITE-13876: --- Summary: Update documentation for 2.9.1 release Key: IGNITE-13876 URL: https://issues.apache.org/jira/browse/IGNITE-13876 Project: Ignite Issue Type: Bug Components: documentation Reporter: Yaroslav Molochkov Assignee: Yaroslav Molochkov The update should reflect changes made to system views(BINARY_METADATA and DISTRIBUTED_METASTORAGE) and metrics (RebalancingPartitionsTotal) -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Metastorage limitations
Hello, Denis. It’s a known issue for me. Metastore is a private API, isn’t it? AFAICU it can occur for two reasons: * User migrates from custom Ignite fork that has private improvements or plugins that write to the metastore. * We have a blocker bug and just remove some internal class that can be written into metastore from distribution. I planned to fix it with some system flag. During startup administrator just sets a list of the metastore items that should be ignored. Please, take a look at the PR [1] WDYT? > it’s better to limit the metastorage with storing primitives only I think that ability to write object is very useful and should stay. [1] https://github.com/apache/ignite/pull/8221 > 18 дек. 2020 г., в 12:06, Mekhanikov Denis написал(а): > > Hi everyone! > > Ignite has a limitation that it can’t work with custom classes put into > metastorage: https://issues.apache.org/jira/browse/IGNITE-13642 > If you put a POJO into the metastorage, then Ignite will try to deserialize > it using the classes it finds on the classpath. If it can’t do the > deserialization, then the node will fail. > > There is an opinion that the metastorage wasn’t design for a case when > classes that can disappear from Ignite distribution. > If we follow this path, then it’s better to limit the metastorage with > storing primitives only, so that it’s impossible to occasionally put anything > breaking. > If a piece of configuration is put into the metastorage by a plugin, then the > plugin will be in charge of deserializing the configuration, and not Ignite. > > Alternatively we can try to fix the metastorage and make it ignore > deserialization errors when they occur. > > What do you think? > > Denis
Metastorage limitations
Hi everyone! Ignite has a limitation that it can’t work with custom classes put into metastorage: https://issues.apache.org/jira/browse/IGNITE-13642 If you put a POJO into the metastorage, then Ignite will try to deserialize it using the classes it finds on the classpath. If it can’t do the deserialization, then the node will fail. There is an opinion that the metastorage wasn’t design for a case when classes that can disappear from Ignite distribution. If we follow this path, then it’s better to limit the metastorage with storing primitives only, so that it’s impossible to occasionally put anything breaking. If a piece of configuration is put into the metastorage by a plugin, then the plugin will be in charge of deserializing the configuration, and not Ignite. Alternatively we can try to fix the metastorage and make it ignore deserialization errors when they occur. What do you think? Denis
