Re: [DISCUSSION] ignite-extension - ignite-spring-boot-autoconfigurer release.
Hi Denis, As discussed with Alexey I have captured the discussion details in confluence wiki page. I have not received any concerns or follow up questions on the release process. I can certainly pause and continue to work on current migration of existing modules if more time required for the review process for releases. With respect to releases all the extensions need to be verified for an upcoming release and updated if needed (with the version increase only for those updated) We can release our first version for ignite-extensions modules as 1.0.0 pointing to 2.7.6 latest released version while the master branch can continued to be verified as per 2.9.0-SNAPSHOT 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 you have any feedback. Regards, Saikat On Fri, Feb 7, 2020 at 12:16 PM Ivan Pavlukhin wrote: > Some more thoughts. > > I think we can try out a first release and decide if everything is ok > along the way. I suppose that we should run tests with supported > Ignite versions (perhaps not all) and provide results. And finally > there will be a release vote. > > Best regards, > Ivan Pavlukhin > > пт, 7 февр. 2020 г. в 19:43, Denis Magda : > > > > Folks, have we agreed on the release process? Saikat, could you point all > > of us to a related discussion. If my memory doesn't fail me Alex > Goncharuk > > also wanted to step in before we do the first release. > > > > - > > Denis > > > > > > On Fri, Feb 7, 2020 at 8:02 AM Saikat Maitra > > wrote: > > > > > Hi Nikolay, Ivan, Denis > > > > > > I think we can release for spring boot autoconfigure module. > > > > > > > > > I will also go ahead and make release for flink ext. > > > > > > I have pending PR for flume and zeromq, if I can get review and > approval I > > > can go ahead and merge and release these modules as well. > > > > > > Regards > > > Saikat > > > > > > On Fri, 7 Feb 2020 at 2:06 AM, Nikolay Izhikov > > > wrote: > > > > > > > Thanks for clarification. > > > > > > > > Igniters, I will proceed with the release in the next few days if > there > > > is > > > > no objections on it. > > > > > > > > > 7 февр. 2020 г., в 10:57, Ivan Pavlukhin > > > > написал(а): > > > > > > > > > > Hi Nikolay, > > > > > > > > > > In fact I did not mean anything supernatural. A scheme you > mentioned > > > > >> I thought we just release module with the 1.0.0 version and > specify > > > > supported Ignite version somewhere in the documentation. > > > > > sounds fine to me. > > > > > > > > > > Best regards, > > > > > Ivan Pavlukhin > > > > > > > > > > чт, 6 февр. 2020 г. в 15:00, Nikolay Izhikov >: > > > > >> > > > > >> Hello, Ivan. > > > > >> > > > > >>> As usual we need to decide about versioning and a correspondence > to > > > > Ignite versions > > > > >>> As we are going to have a separate release cycle I can imagine an > > > > independent versioning scheme with a range of supported Ignite > versions. > > > > >> > > > > >> Please, clarify, what do you mean? > > > > >> Do you have any idea how it should be implemented? > > > > >> > > > > >> I thought we just release module with the 1.0.0 version and > specify > > > > supported Ignite version somewhere in the documentation. > > > > >> > > > > >>> 6 февр. 2020 г., в 11:15, Ivan Pavlukhin > > > > написал(а): > > > > >>> > > > > >>> Nikolay, > > > > >>> > > > > >>> Thank you for driving it! It is great to establish this process > in > > > > >>> practice earlier because it seems that we need to release a Flink > > > > >>> integration soon because Ignite 2.8 is going to be released > without > > > > >>> that integration bundled. > > > > >>> > > > > >>> As usual we need to decide about versioning and a correspondence > to > > > > >>> Ignite versions. As we are going to have a separate release > cycle I > > > > >>> can imagine an independent versioning scheme with a range of > > > supported > > > > >>> Ignite versions. > > > > >>> > > > > >>> Also I think it is a good idea to update ignite-extensions > README on > > > > >>> GitHub and provide a link to relevant TC jobs. > > > > >>> > > > > >>> Best regards, > > > > >>> Ivan Pavlukhin > > > > >>> > > > > >>> ср, 5 февр. 2020 г. в 17:44, Denis Magda : > > > > > > > > Alex, did you have a chance to review Saikat’s changes related > to > > > the > > > > extensions repository organization and release approach? > > > > > > > > Denis > > > > > > > > On Wednesday, February 5, 2020, Nikolay Izhikov < > > > nizhi...@apache.org> > > > > wrote: > > > > > > > > > Hello, Igniters. > > > > > > > > > > We don't have a release process for newly created >
Re: Mark MVCC with @IgniteExperimental
Folks, Do we have a consensus so far that MVCC should be annotated with @IgniteExperimental? Are there any objections? Best regards, Ivan Pavlukhin пт, 7 февр. 2020 г. в 15:58, Roman Kondakov : > > I absolutely agree with Alexey that MVCC architecture should be > completely reviewed. Current implementation is uncompetitive with other > solutions. It is slow by design. Here are some my points: > - we use central coordinator for transactions ordering. This is very > similar to what Calvin [1] systems do. But unlike them we also use 2pc > for distributed commit. So, we always have several additional network > hops for each transaction and every Calvin system (FaunaDB, YandexDB) > will outperform Ignite by design. > - We write uncommitted data to the page memory and WAL and this slows > down transactions even more. > > I am a supporter of complete revising of the MVCC design. > > [1] http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf > > -- > Kind Regards > Roman Kondakov > > > On 07.02.2020 15:21, Alexei Scherbakov wrote: > > My point is MVCC should be redone from scratch without messing with other > > pars of code. > > > > Currently it's spaghetti unmaintanable code. > > > > пт, 7 февр. 2020 г. в 14:52, Ivan Pavlukhin : > > > >> My humble opinion. > >> > >> We need MVCC because it is our way to SQL transactions. SQL is a very > >> important user API (as you might know there is an active work on new > >> SQL engine). Fair SQL transactions is a supplementary and quite needed > >> feature, users ask about it on user list. I believe it is a future of > >> Ignite. > >> > >> Best regards, > >> Ivan Pavlukhin > >> > >> пт, 7 февр. 2020 г. в 13:23, Seliverstov Igor : > >>> > >>> Note that someone uses it > >>> > >>> Main problem is a recovery process when persistence enabled and a > >> cluster have more than one node. > >>> > >>> It is a problem even for regular transactional caches, the main > >> difference - MVCC detects any inconsistencies while regular transactional > >> caches may ignore it without any notification > >>> > >>> In other cases it works fine and provides promised guaranties. > >>> > >>> Of course there are several minor issues like performance ones, but > >> there is a plan how to solve them (I could share it if anybody is curious) > >>> > >>> My opinion we should solve consistency issues first and finalize MVCC > >> after that. > >>> > >>> Until that it’s OK to have it as experimental feature. > >>> > >>> Regards, > >>> Igor > >>> > 6 февр. 2020 г., в 21:25, Alexei Scherbakov < > >> alexey.scherbak...@gmail.com> написал(а): > > I'm strongly support removal of MVCC from master. > > At the current state it bloats code base and should be reworked from > scratch using separate code base. > > чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev < > >> ilya.kasnach...@gmail.com>: > > > Hello! > > > > Please keep in mind that you need to create a separate proposal voting > > thread if you really like it to count. I wonder if Dmitry Pavlov can > >> help > > us with the procedure. > > > > Otherwise, I think it makes total sense to restrict MVCC clusters to > >> only > > have MVCC caches or REPLICATED TRANSACTIONAL caches (are they > >> compatible in > > our current implementation) and no ATOMIC caches at all. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov : > > > >> Ilya, > >> > >> > >> 1. MVCC support requires code maintenance for other developed > >> features > >> even if has not used and disabled. Currently, we've got an x2 level > >> of > >> difficulty for implementation of new features. > >> > >> 2. It would be much easy to develop and support clusters with > >> mvcc-caches only rather than have a mixed configuration. With this > >> option we can dramatically reduce the amount of codebase removing > >> from > >> mvcc-branch local, atomic, tx caches. > >> > >> > >> So, I'm +1 to remove it from the master branch and mark the current > >> API with @IgniteExperimental. > >> > >> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev < > >> ilya.kasnach...@gmail.com> > >> wrote: > >>> > >>> Hello! > >>> > >>> Why would we drop MVCC!? > >>> > >>> I can totally imagine a scenario where a large Ignite user surfaces > > with > >>> fixes for MVCC mode, if it is kept as an experimental feature. Then > > maybe > >>> it will graduate to beta some time in future. > >>> > >>> If it does too much strain on the TC, let's discuss that, but I > >> don't > >>> remember problems with TC load lately, so maybe this is a moot > >> point. > >>> > >>> Regards, > >>> -- > >>> Ilya Kasnacheev > >>> > >>> > >>> чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov : > >>> > > By the way, is there any reason to
Re: [DISCUSSION] ignite-extension - ignite-spring-boot-autoconfigurer release.
Some more thoughts. I think we can try out a first release and decide if everything is ok along the way. I suppose that we should run tests with supported Ignite versions (perhaps not all) and provide results. And finally there will be a release vote. Best regards, Ivan Pavlukhin пт, 7 февр. 2020 г. в 19:43, Denis Magda : > > Folks, have we agreed on the release process? Saikat, could you point all > of us to a related discussion. If my memory doesn't fail me Alex Goncharuk > also wanted to step in before we do the first release. > > - > Denis > > > On Fri, Feb 7, 2020 at 8:02 AM Saikat Maitra > wrote: > > > Hi Nikolay, Ivan, Denis > > > > I think we can release for spring boot autoconfigure module. > > > > > > I will also go ahead and make release for flink ext. > > > > I have pending PR for flume and zeromq, if I can get review and approval I > > can go ahead and merge and release these modules as well. > > > > Regards > > Saikat > > > > On Fri, 7 Feb 2020 at 2:06 AM, Nikolay Izhikov > > wrote: > > > > > Thanks for clarification. > > > > > > Igniters, I will proceed with the release in the next few days if there > > is > > > no objections on it. > > > > > > > 7 февр. 2020 г., в 10:57, Ivan Pavlukhin > > > написал(а): > > > > > > > > Hi Nikolay, > > > > > > > > In fact I did not mean anything supernatural. A scheme you mentioned > > > >> I thought we just release module with the 1.0.0 version and specify > > > supported Ignite version somewhere in the documentation. > > > > sounds fine to me. > > > > > > > > Best regards, > > > > Ivan Pavlukhin > > > > > > > > чт, 6 февр. 2020 г. в 15:00, Nikolay Izhikov : > > > >> > > > >> Hello, Ivan. > > > >> > > > >>> As usual we need to decide about versioning and a correspondence to > > > Ignite versions > > > >>> As we are going to have a separate release cycle I can imagine an > > > independent versioning scheme with a range of supported Ignite versions. > > > >> > > > >> Please, clarify, what do you mean? > > > >> Do you have any idea how it should be implemented? > > > >> > > > >> I thought we just release module with the 1.0.0 version and specify > > > supported Ignite version somewhere in the documentation. > > > >> > > > >>> 6 февр. 2020 г., в 11:15, Ivan Pavlukhin > > > написал(а): > > > >>> > > > >>> Nikolay, > > > >>> > > > >>> Thank you for driving it! It is great to establish this process in > > > >>> practice earlier because it seems that we need to release a Flink > > > >>> integration soon because Ignite 2.8 is going to be released without > > > >>> that integration bundled. > > > >>> > > > >>> As usual we need to decide about versioning and a correspondence to > > > >>> Ignite versions. As we are going to have a separate release cycle I > > > >>> can imagine an independent versioning scheme with a range of > > supported > > > >>> Ignite versions. > > > >>> > > > >>> Also I think it is a good idea to update ignite-extensions README on > > > >>> GitHub and provide a link to relevant TC jobs. > > > >>> > > > >>> Best regards, > > > >>> Ivan Pavlukhin > > > >>> > > > >>> ср, 5 февр. 2020 г. в 17:44, Denis Magda : > > > > > > Alex, did you have a chance to review Saikat’s changes related to > > the > > > extensions repository organization and release approach? > > > > > > Denis > > > > > > On Wednesday, February 5, 2020, Nikolay Izhikov < > > nizhi...@apache.org> > > > wrote: > > > > > > > Hello, Igniters. > > > > > > > > We don't have a release process for newly created ignite-extensions > > > > modules. > > > > I want to release two modules: > > > > > > > > * ignite-spring-boot-autoconfigure > > > > * ignite-client-spring-boot-autoconfigure > > > > > > > > Let's discuss it. > > > > > > > > Any objections to it? > > > > What should be done before release? > > > > > > > > > > > > > -- > > > - > > > Denis > > > >> > > > > > > > >
Re: [DISCUSSION] ignite-extension - ignite-spring-boot-autoconfigurer release.
Folks, have we agreed on the release process? Saikat, could you point all of us to a related discussion. If my memory doesn't fail me Alex Goncharuk also wanted to step in before we do the first release. - Denis On Fri, Feb 7, 2020 at 8:02 AM Saikat Maitra wrote: > Hi Nikolay, Ivan, Denis > > I think we can release for spring boot autoconfigure module. > > > I will also go ahead and make release for flink ext. > > I have pending PR for flume and zeromq, if I can get review and approval I > can go ahead and merge and release these modules as well. > > Regards > Saikat > > On Fri, 7 Feb 2020 at 2:06 AM, Nikolay Izhikov > wrote: > > > Thanks for clarification. > > > > Igniters, I will proceed with the release in the next few days if there > is > > no objections on it. > > > > > 7 февр. 2020 г., в 10:57, Ivan Pavlukhin > > написал(а): > > > > > > Hi Nikolay, > > > > > > In fact I did not mean anything supernatural. A scheme you mentioned > > >> I thought we just release module with the 1.0.0 version and specify > > supported Ignite version somewhere in the documentation. > > > sounds fine to me. > > > > > > Best regards, > > > Ivan Pavlukhin > > > > > > чт, 6 февр. 2020 г. в 15:00, Nikolay Izhikov : > > >> > > >> Hello, Ivan. > > >> > > >>> As usual we need to decide about versioning and a correspondence to > > Ignite versions > > >>> As we are going to have a separate release cycle I can imagine an > > independent versioning scheme with a range of supported Ignite versions. > > >> > > >> Please, clarify, what do you mean? > > >> Do you have any idea how it should be implemented? > > >> > > >> I thought we just release module with the 1.0.0 version and specify > > supported Ignite version somewhere in the documentation. > > >> > > >>> 6 февр. 2020 г., в 11:15, Ivan Pavlukhin > > написал(а): > > >>> > > >>> Nikolay, > > >>> > > >>> Thank you for driving it! It is great to establish this process in > > >>> practice earlier because it seems that we need to release a Flink > > >>> integration soon because Ignite 2.8 is going to be released without > > >>> that integration bundled. > > >>> > > >>> As usual we need to decide about versioning and a correspondence to > > >>> Ignite versions. As we are going to have a separate release cycle I > > >>> can imagine an independent versioning scheme with a range of > supported > > >>> Ignite versions. > > >>> > > >>> Also I think it is a good idea to update ignite-extensions README on > > >>> GitHub and provide a link to relevant TC jobs. > > >>> > > >>> Best regards, > > >>> Ivan Pavlukhin > > >>> > > >>> ср, 5 февр. 2020 г. в 17:44, Denis Magda : > > > > Alex, did you have a chance to review Saikat’s changes related to > the > > extensions repository organization and release approach? > > > > Denis > > > > On Wednesday, February 5, 2020, Nikolay Izhikov < > nizhi...@apache.org> > > wrote: > > > > > Hello, Igniters. > > > > > > We don't have a release process for newly created ignite-extensions > > > modules. > > > I want to release two modules: > > > > > > * ignite-spring-boot-autoconfigure > > > * ignite-client-spring-boot-autoconfigure > > > > > > Let's discuss it. > > > > > > Any objections to it? > > > What should be done before release? > > > > > > > > > -- > > - > > Denis > > >> > > > > >
Re: [DISCUSSION] ignite-extension - ignite-spring-boot-autoconfigurer release.
Hi Nikolay, Ivan, Denis I think we can release for spring boot autoconfigure module. I will also go ahead and make release for flink ext. I have pending PR for flume and zeromq, if I can get review and approval I can go ahead and merge and release these modules as well. Regards Saikat On Fri, 7 Feb 2020 at 2:06 AM, Nikolay Izhikov wrote: > Thanks for clarification. > > Igniters, I will proceed with the release in the next few days if there is > no objections on it. > > > 7 февр. 2020 г., в 10:57, Ivan Pavlukhin > написал(а): > > > > Hi Nikolay, > > > > In fact I did not mean anything supernatural. A scheme you mentioned > >> I thought we just release module with the 1.0.0 version and specify > supported Ignite version somewhere in the documentation. > > sounds fine to me. > > > > Best regards, > > Ivan Pavlukhin > > > > чт, 6 февр. 2020 г. в 15:00, Nikolay Izhikov : > >> > >> Hello, Ivan. > >> > >>> As usual we need to decide about versioning and a correspondence to > Ignite versions > >>> As we are going to have a separate release cycle I can imagine an > independent versioning scheme with a range of supported Ignite versions. > >> > >> Please, clarify, what do you mean? > >> Do you have any idea how it should be implemented? > >> > >> I thought we just release module with the 1.0.0 version and specify > supported Ignite version somewhere in the documentation. > >> > >>> 6 февр. 2020 г., в 11:15, Ivan Pavlukhin > написал(а): > >>> > >>> Nikolay, > >>> > >>> Thank you for driving it! It is great to establish this process in > >>> practice earlier because it seems that we need to release a Flink > >>> integration soon because Ignite 2.8 is going to be released without > >>> that integration bundled. > >>> > >>> As usual we need to decide about versioning and a correspondence to > >>> Ignite versions. As we are going to have a separate release cycle I > >>> can imagine an independent versioning scheme with a range of supported > >>> Ignite versions. > >>> > >>> Also I think it is a good idea to update ignite-extensions README on > >>> GitHub and provide a link to relevant TC jobs. > >>> > >>> Best regards, > >>> Ivan Pavlukhin > >>> > >>> ср, 5 февр. 2020 г. в 17:44, Denis Magda : > > Alex, did you have a chance to review Saikat’s changes related to the > extensions repository organization and release approach? > > Denis > > On Wednesday, February 5, 2020, Nikolay Izhikov > wrote: > > > Hello, Igniters. > > > > We don't have a release process for newly created ignite-extensions > > modules. > > I want to release two modules: > > > > * ignite-spring-boot-autoconfigure > > * ignite-client-spring-boot-autoconfigure > > > > Let's discuss it. > > > > Any objections to it? > > What should be done before release? > > > > > -- > - > Denis > >> > >
[jira] [Created] (IGNITE-12641) IgniteSequenceInternalCleanupTest flacky after IGNITE-12598
Nikolay Izhikov created IGNITE-12641: Summary: IgniteSequenceInternalCleanupTest flacky after IGNITE-12598 Key: IGNITE-12641 URL: https://issues.apache.org/jira/browse/IGNITE-12641 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov IgniteSequenceInternalCleanupTest#deactivate is flacky after IGNITE-12598 The test expects that cache metrics will be reset after cluster deactivation and subsequent cache stop. But this was changed intentionally in IGNITE-12598. Test not always fail because it asserts cluster metrics value which updated concurrently with the test thread. We should fix the assert. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12640) Update readme's advanced security page
Ryabov Dmitrii created IGNITE-12640:
---
Summary: Update readme's advanced security page
Key: IGNITE-12640
URL: https://issues.apache.org/jira/browse/IGNITE-12640
Project: Ignite
Issue Type: Task
Reporter: Ryabov Dmitrii
Add next paragraph to advanced security page [1] as last paragraph of the
Authorization section.
{noformat}
Also, custom 'GridSecurityProcessor' let you check thin client's additional
info inside both authentication and authorization. You can get info from
'AuthenticationContext.nodeAttributes()' map. To setup additional info use
'setUserAttributes()' for client configuration or 'userAttributesFactory'
parameter for JDBC connection.
{noformat}
[1] https://apacheignite.readme.io/docs/advanced-security
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Mark MVCC with @IgniteExperimental
I absolutely agree with Alexey that MVCC architecture should be completely reviewed. Current implementation is uncompetitive with other solutions. It is slow by design. Here are some my points: - we use central coordinator for transactions ordering. This is very similar to what Calvin [1] systems do. But unlike them we also use 2pc for distributed commit. So, we always have several additional network hops for each transaction and every Calvin system (FaunaDB, YandexDB) will outperform Ignite by design. - We write uncommitted data to the page memory and WAL and this slows down transactions even more. I am a supporter of complete revising of the MVCC design. [1] http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf -- Kind Regards Roman Kondakov On 07.02.2020 15:21, Alexei Scherbakov wrote: > My point is MVCC should be redone from scratch without messing with other > pars of code. > > Currently it's spaghetti unmaintanable code. > > пт, 7 февр. 2020 г. в 14:52, Ivan Pavlukhin : > >> My humble opinion. >> >> We need MVCC because it is our way to SQL transactions. SQL is a very >> important user API (as you might know there is an active work on new >> SQL engine). Fair SQL transactions is a supplementary and quite needed >> feature, users ask about it on user list. I believe it is a future of >> Ignite. >> >> Best regards, >> Ivan Pavlukhin >> >> пт, 7 февр. 2020 г. в 13:23, Seliverstov Igor : >>> >>> Note that someone uses it >>> >>> Main problem is a recovery process when persistence enabled and a >> cluster have more than one node. >>> >>> It is a problem even for regular transactional caches, the main >> difference - MVCC detects any inconsistencies while regular transactional >> caches may ignore it without any notification >>> >>> In other cases it works fine and provides promised guaranties. >>> >>> Of course there are several minor issues like performance ones, but >> there is a plan how to solve them (I could share it if anybody is curious) >>> >>> My opinion we should solve consistency issues first and finalize MVCC >> after that. >>> >>> Until that it’s OK to have it as experimental feature. >>> >>> Regards, >>> Igor >>> 6 февр. 2020 г., в 21:25, Alexei Scherbakov < >> alexey.scherbak...@gmail.com> написал(а): I'm strongly support removal of MVCC from master. At the current state it bloats code base and should be reworked from scratch using separate code base. чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev < >> ilya.kasnach...@gmail.com>: > Hello! > > Please keep in mind that you need to create a separate proposal voting > thread if you really like it to count. I wonder if Dmitry Pavlov can >> help > us with the procedure. > > Otherwise, I think it makes total sense to restrict MVCC clusters to >> only > have MVCC caches or REPLICATED TRANSACTIONAL caches (are they >> compatible in > our current implementation) and no ATOMIC caches at all. > > Regards, > -- > Ilya Kasnacheev > > > чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov : > >> Ilya, >> >> >> 1. MVCC support requires code maintenance for other developed >> features >> even if has not used and disabled. Currently, we've got an x2 level >> of >> difficulty for implementation of new features. >> >> 2. It would be much easy to develop and support clusters with >> mvcc-caches only rather than have a mixed configuration. With this >> option we can dramatically reduce the amount of codebase removing >> from >> mvcc-branch local, atomic, tx caches. >> >> >> So, I'm +1 to remove it from the master branch and mark the current >> API with @IgniteExperimental. >> >> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev < >> ilya.kasnach...@gmail.com> >> wrote: >>> >>> Hello! >>> >>> Why would we drop MVCC!? >>> >>> I can totally imagine a scenario where a large Ignite user surfaces > with >>> fixes for MVCC mode, if it is kept as an experimental feature. Then > maybe >>> it will graduate to beta some time in future. >>> >>> If it does too much strain on the TC, let's discuss that, but I >> don't >>> remember problems with TC load lately, so maybe this is a moot >> point. >>> >>> Regards, >>> -- >>> Ilya Kasnacheev >>> >>> >>> чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov : >>> > By the way, is there any reason to have this code in the master >> branch I support removal MVCC from master. > 6 февр. 2020 г., в 15:26, Andrey Gura > написал(а): > > +1 > > By the way, is there any reason to have this code in the master > branch? It seems feature is in unsupportable state and just wastes > TC > time and our effort to support MVCC related tests. > > On Thu, Feb 6,
Re: Mark MVCC with @IgniteExperimental
My point is MVCC should be redone from scratch without messing with other pars of code. Currently it's spaghetti unmaintanable code. пт, 7 февр. 2020 г. в 14:52, Ivan Pavlukhin : > My humble opinion. > > We need MVCC because it is our way to SQL transactions. SQL is a very > important user API (as you might know there is an active work on new > SQL engine). Fair SQL transactions is a supplementary and quite needed > feature, users ask about it on user list. I believe it is a future of > Ignite. > > Best regards, > Ivan Pavlukhin > > пт, 7 февр. 2020 г. в 13:23, Seliverstov Igor : > > > > Note that someone uses it > > > > Main problem is a recovery process when persistence enabled and a > cluster have more than one node. > > > > It is a problem even for regular transactional caches, the main > difference - MVCC detects any inconsistencies while regular transactional > caches may ignore it without any notification > > > > In other cases it works fine and provides promised guaranties. > > > > Of course there are several minor issues like performance ones, but > there is a plan how to solve them (I could share it if anybody is curious) > > > > My opinion we should solve consistency issues first and finalize MVCC > after that. > > > > Until that it’s OK to have it as experimental feature. > > > > Regards, > > Igor > > > > > 6 февр. 2020 г., в 21:25, Alexei Scherbakov < > alexey.scherbak...@gmail.com> написал(а): > > > > > > I'm strongly support removal of MVCC from master. > > > > > > At the current state it bloats code base and should be reworked from > > > scratch using separate code base. > > > > > > чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev < > ilya.kasnach...@gmail.com>: > > > > > >> Hello! > > >> > > >> Please keep in mind that you need to create a separate proposal voting > > >> thread if you really like it to count. I wonder if Dmitry Pavlov can > help > > >> us with the procedure. > > >> > > >> Otherwise, I think it makes total sense to restrict MVCC clusters to > only > > >> have MVCC caches or REPLICATED TRANSACTIONAL caches (are they > compatible in > > >> our current implementation) and no ATOMIC caches at all. > > >> > > >> Regards, > > >> -- > > >> Ilya Kasnacheev > > >> > > >> > > >> чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov : > > >> > > >>> Ilya, > > >>> > > >>> > > >>> 1. MVCC support requires code maintenance for other developed > features > > >>> even if has not used and disabled. Currently, we've got an x2 level > of > > >>> difficulty for implementation of new features. > > >>> > > >>> 2. It would be much easy to develop and support clusters with > > >>> mvcc-caches only rather than have a mixed configuration. With this > > >>> option we can dramatically reduce the amount of codebase removing > from > > >>> mvcc-branch local, atomic, tx caches. > > >>> > > >>> > > >>> So, I'm +1 to remove it from the master branch and mark the current > > >>> API with @IgniteExperimental. > > >>> > > >>> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > >>> wrote: > > > > Hello! > > > > Why would we drop MVCC!? > > > > I can totally imagine a scenario where a large Ignite user surfaces > > >> with > > fixes for MVCC mode, if it is kept as an experimental feature. Then > > >> maybe > > it will graduate to beta some time in future. > > > > If it does too much strain on the TC, let's discuss that, but I > don't > > remember problems with TC load lately, so maybe this is a moot > point. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov : > > > > >> By the way, is there any reason to have this code in the master > > >>> branch > > > > > > I support removal MVCC from master. > > > > > > > > >> 6 февр. 2020 г., в 15:26, Andrey Gura > > >> написал(а): > > >> > > >> +1 > > >> > > >> By the way, is there any reason to have this code in the master > > >> branch? It seems feature is in unsupportable state and just wastes > > >> TC > > >> time and our effort to support MVCC related tests. > > >> > > >> On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk > > >> wrote: > > >>> > > >>> Agree, let's mark MVCC experimental. > > >>> > > >>> Stephen, the annotation serves as an additional > > >> documentation-style > > > marker. > > >>> For now there are no compile-time warnings when the API is used. > > >>> > > >>> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington < > > >>> stephen.darling...@gridgain.com>: > > >>> > > Yes! I’ve already seen people try to use this without awareness > > >>> that > > > it’s > > not production ready. > > > > What happens with the annotation, incidentally? Is it just in > the > > documentation or do you get a compile-time warning? > > > > > On 6 Feb
[jira] [Created] (IGNITE-12639) Calcite integration. DML support.
Igor Seliverstov created IGNITE-12639: - Summary: Calcite integration. DML support. Key: IGNITE-12639 URL: https://issues.apache.org/jira/browse/IGNITE-12639 Project: Ignite Issue Type: New Feature Reporter: Igor Seliverstov Assignee: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] SQL system views content
Ivan. My understanding of system views reflected in IEP-35: With the system views we should answer to the user question - «What objects are existing in my node?» > From a (unit) test I cannot figure out how a proxy index is different from an > underlying one from a user perspective. > Could you please elaborate? I don’t know the answer, for now. But this object(proxy index) exists in the node and should be viewed by the administrator in the system view. It seems, we should update documentation and explain to the user meaning of the proxy indexes. > 7 февр. 2020 г., в 14:37, Ivan Pavlukhin написал(а): > > Nikolay, > > I have not filed any ticket yet. I would like to discuss first. > >> Yes, this was made intentionally. >> I think we shouldn’t hide internal details from the user in the system views. > > Regarding proxy indices Cannot immediately agree here. My > understanding is that the view in question should contain information > which a user can use for managing SQL workflows. E.g. for a query > optimization. From a (unit) test I cannot figure out how a proxy index > is different from an underlying one from a user perspective. Could you > please elaborate? > > Best regards, > Ivan Pavlukhin > > пт, 7 февр. 2020 г. в 13:33, Nikolay Izhikov : >> >>> 1. Columns related to a cache group information disappeared. >> >> Information about cache group can be gathered from SYS.CACHES and >> SYS.CACHE_GROUPS. >> >>> 2. "proxy" indexes info is now displayed in the view. >> >> Yes, this was made intentionally. >> I think we shouldn’t hide internal details from the user in the system views. >> >> Please, note, that there is no Ignite release with index system view, for >> now. >> >>> 7 февр. 2020 г., в 13:26, Ivan Pavlukhin написал(а): >>> >>> Nikolay, >>> >>> Recently I noticed some changes in SQL indexes view content introduced >>> in [1]. Among changes I noticed: >>> 1. Columns related to a cache group information disappeared. >>> 2. "proxy" indexes info is now displayed in the view. >>> >>> Was this changes made intentionally? Historically there were following >>> tickets [2, 3] for indexes system views. And as [3] added a cache >>> group info but [1] removed it makes me think that some changes appear >>> not intentionally. From the first glance it seems to me that we should >>> restore [3] behavior. Correct me if I am wrong. >>> >>> [1] https://issues.apache.org/jira/browse/IGNITE-12213 >>> [2] https://issues.apache.org/jira/browse/IGNITE-11056 >>> [3] https://issues.apache.org/jira/browse/IGNITE-11443 >>> >>> Best regards, >>> Ivan Pavlukhin >>
Re: [DISCUSSION][IEP-39] Management API to cancel user provided tasks and queries.
> IMHO, the control utility is a more natural way of administration/control of the cluster instead of JMX, for example. It’s questionable. I don’t mind to improve control.sh in this IEP. But, we should discuss to topic - what management utilities we are providing *AND* supporting and how the should work. As far as I know we have some REST API, but it seems abandoned and not supported. > 7 февр. 2020 г., в 14:45, Вячеслав Коптилин > написал(а): > > Hi Nikolay, > > Yes, I think we should add this API to the control utility as well. > IMHO, the control utility is a more natural way of administration/control > of the cluster instead of JMX, for example. > > Thanks, > S. > > пт, 7 февр. 2020 г. в 11:38, Nikolay Izhikov : > >> Hello, Vyacheslav. >> >>> It seems to me we missed API that should be introduced into control >> utility. >> >> Do you think we should support control.sh for cancel tasks? >> >> >>> 7 февр. 2020 г., в 11:04, Alexey Goncharuk >> написал(а): >>> >>> Alexei, >>> >>> I agree that there should be no principal difficulty with the unique ID >> for >>> each cancellable object, but I also see Nikolay's point about the wrong >>> copy-paste. >>> >>> I like minimalistic APIs, but in this case the price of a mistake may be >>> high. Let's let a wider circle of community members to speak out. >> >>
Re: Mark MVCC with @IgniteExperimental
My humble opinion. We need MVCC because it is our way to SQL transactions. SQL is a very important user API (as you might know there is an active work on new SQL engine). Fair SQL transactions is a supplementary and quite needed feature, users ask about it on user list. I believe it is a future of Ignite. Best regards, Ivan Pavlukhin пт, 7 февр. 2020 г. в 13:23, Seliverstov Igor : > > Note that someone uses it > > Main problem is a recovery process when persistence enabled and a cluster > have more than one node. > > It is a problem even for regular transactional caches, the main difference - > MVCC detects any inconsistencies while regular transactional caches may > ignore it without any notification > > In other cases it works fine and provides promised guaranties. > > Of course there are several minor issues like performance ones, but there is > a plan how to solve them (I could share it if anybody is curious) > > My opinion we should solve consistency issues first and finalize MVCC after > that. > > Until that it’s OK to have it as experimental feature. > > Regards, > Igor > > > 6 февр. 2020 г., в 21:25, Alexei Scherbakov > > написал(а): > > > > I'm strongly support removal of MVCC from master. > > > > At the current state it bloats code base and should be reworked from > > scratch using separate code base. > > > > чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev : > > > >> Hello! > >> > >> Please keep in mind that you need to create a separate proposal voting > >> thread if you really like it to count. I wonder if Dmitry Pavlov can help > >> us with the procedure. > >> > >> Otherwise, I think it makes total sense to restrict MVCC clusters to only > >> have MVCC caches or REPLICATED TRANSACTIONAL caches (are they compatible in > >> our current implementation) and no ATOMIC caches at all. > >> > >> Regards, > >> -- > >> Ilya Kasnacheev > >> > >> > >> чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov : > >> > >>> Ilya, > >>> > >>> > >>> 1. MVCC support requires code maintenance for other developed features > >>> even if has not used and disabled. Currently, we've got an x2 level of > >>> difficulty for implementation of new features. > >>> > >>> 2. It would be much easy to develop and support clusters with > >>> mvcc-caches only rather than have a mixed configuration. With this > >>> option we can dramatically reduce the amount of codebase removing from > >>> mvcc-branch local, atomic, tx caches. > >>> > >>> > >>> So, I'm +1 to remove it from the master branch and mark the current > >>> API with @IgniteExperimental. > >>> > >>> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev > >>> wrote: > > Hello! > > Why would we drop MVCC!? > > I can totally imagine a scenario where a large Ignite user surfaces > >> with > fixes for MVCC mode, if it is kept as an experimental feature. Then > >> maybe > it will graduate to beta some time in future. > > If it does too much strain on the TC, let's discuss that, but I don't > remember problems with TC load lately, so maybe this is a moot point. > > Regards, > -- > Ilya Kasnacheev > > > чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov : > > >> By the way, is there any reason to have this code in the master > >>> branch > > > > I support removal MVCC from master. > > > > > >> 6 февр. 2020 г., в 15:26, Andrey Gura > >> написал(а): > >> > >> +1 > >> > >> By the way, is there any reason to have this code in the master > >> branch? It seems feature is in unsupportable state and just wastes > >> TC > >> time and our effort to support MVCC related tests. > >> > >> On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk > >> wrote: > >>> > >>> Agree, let's mark MVCC experimental. > >>> > >>> Stephen, the annotation serves as an additional > >> documentation-style > > marker. > >>> For now there are no compile-time warnings when the API is used. > >>> > >>> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington < > >>> stephen.darling...@gridgain.com>: > >>> > Yes! I’ve already seen people try to use this without awareness > >>> that > > it’s > not production ready. > > What happens with the annotation, incidentally? Is it just in the > documentation or do you get a compile-time warning? > > > On 6 Feb 2020, at 11:32, Nikolay Izhikov > >>> wrote: > > > > Hello, Igniters. > > > > Should we mark MVCC feature with the new @IgniteExperimental? > > > > We explicitly note users that MVCC has beta status, for now [1] > > > >> Beta version of Transactional SQL and MVCC > >> In Ignite v2.7, Transactional SQL and MVCC are released as beta > versions to allow users to experiment and share feedback. > >> This version of Transactional SQL and MVCC should not be > >>>
Re: [DISCUSSION][IEP-39] Management API to cancel user provided tasks and queries.
Hi Nikolay, Yes, I think we should add this API to the control utility as well. IMHO, the control utility is a more natural way of administration/control of the cluster instead of JMX, for example. Thanks, S. пт, 7 февр. 2020 г. в 11:38, Nikolay Izhikov : > Hello, Vyacheslav. > > > It seems to me we missed API that should be introduced into control > utility. > > Do you think we should support control.sh for cancel tasks? > > > > 7 февр. 2020 г., в 11:04, Alexey Goncharuk > написал(а): > > > > Alexei, > > > > I agree that there should be no principal difficulty with the unique ID > for > > each cancellable object, but I also see Nikolay's point about the wrong > > copy-paste. > > > > I like minimalistic APIs, but in this case the price of a mistake may be > > high. Let's let a wider circle of community members to speak out. > >
Re: [DISCUSS] SQL system views content
Nikolay, I have not filed any ticket yet. I would like to discuss first. > Yes, this was made intentionally. > I think we shouldn’t hide internal details from the user in the system views. Regarding proxy indices Cannot immediately agree here. My understanding is that the view in question should contain information which a user can use for managing SQL workflows. E.g. for a query optimization. From a (unit) test I cannot figure out how a proxy index is different from an underlying one from a user perspective. Could you please elaborate? Best regards, Ivan Pavlukhin пт, 7 февр. 2020 г. в 13:33, Nikolay Izhikov : > > > 1. Columns related to a cache group information disappeared. > > Information about cache group can be gathered from SYS.CACHES and > SYS.CACHE_GROUPS. > > > 2. "proxy" indexes info is now displayed in the view. > > Yes, this was made intentionally. > I think we shouldn’t hide internal details from the user in the system views. > > Please, note, that there is no Ignite release with index system view, for now. > > > 7 февр. 2020 г., в 13:26, Ivan Pavlukhin написал(а): > > > > Nikolay, > > > > Recently I noticed some changes in SQL indexes view content introduced > > in [1]. Among changes I noticed: > > 1. Columns related to a cache group information disappeared. > > 2. "proxy" indexes info is now displayed in the view. > > > > Was this changes made intentionally? Historically there were following > > tickets [2, 3] for indexes system views. And as [3] added a cache > > group info but [1] removed it makes me think that some changes appear > > not intentionally. From the first glance it seems to me that we should > > restore [3] behavior. Correct me if I am wrong. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12213 > > [2] https://issues.apache.org/jira/browse/IGNITE-11056 > > [3] https://issues.apache.org/jira/browse/IGNITE-11443 > > > > Best regards, > > Ivan Pavlukhin >
Re: [DISCUSS] SQL system views content
> 1. Columns related to a cache group information disappeared. Information about cache group can be gathered from SYS.CACHES and SYS.CACHE_GROUPS. > 2. "proxy" indexes info is now displayed in the view. Yes, this was made intentionally. I think we shouldn’t hide internal details from the user in the system views. Please, note, that there is no Ignite release with index system view, for now. > 7 февр. 2020 г., в 13:26, Ivan Pavlukhin написал(а): > > Nikolay, > > Recently I noticed some changes in SQL indexes view content introduced > in [1]. Among changes I noticed: > 1. Columns related to a cache group information disappeared. > 2. "proxy" indexes info is now displayed in the view. > > Was this changes made intentionally? Historically there were following > tickets [2, 3] for indexes system views. And as [3] added a cache > group info but [1] removed it makes me think that some changes appear > not intentionally. From the first glance it seems to me that we should > restore [3] behavior. Correct me if I am wrong. > > [1] https://issues.apache.org/jira/browse/IGNITE-12213 > [2] https://issues.apache.org/jira/browse/IGNITE-11056 > [3] https://issues.apache.org/jira/browse/IGNITE-11443 > > Best regards, > Ivan Pavlukhin
Re: [DISCUSS] SQL system views content
Hello, Ivan. Please, clarify what columns are missed? Do you file a ticket to introduce those fields? > 7 февр. 2020 г., в 13:26, Ivan Pavlukhin написал(а): > > Nikolay, > > Recently I noticed some changes in SQL indexes view content introduced > in [1]. Among changes I noticed: > 1. Columns related to a cache group information disappeared. > 2. "proxy" indexes info is now displayed in the view. > > Was this changes made intentionally? Historically there were following > tickets [2, 3] for indexes system views. And as [3] added a cache > group info but [1] removed it makes me think that some changes appear > not intentionally. From the first glance it seems to me that we should > restore [3] behavior. Correct me if I am wrong. > > [1] https://issues.apache.org/jira/browse/IGNITE-12213 > [2] https://issues.apache.org/jira/browse/IGNITE-11056 > [3] https://issues.apache.org/jira/browse/IGNITE-11443 > > Best regards, > Ivan Pavlukhin
[DISCUSS] SQL system views content
Nikolay, Recently I noticed some changes in SQL indexes view content introduced in [1]. Among changes I noticed: 1. Columns related to a cache group information disappeared. 2. "proxy" indexes info is now displayed in the view. Was this changes made intentionally? Historically there were following tickets [2, 3] for indexes system views. And as [3] added a cache group info but [1] removed it makes me think that some changes appear not intentionally. From the first glance it seems to me that we should restore [3] behavior. Correct me if I am wrong. [1] https://issues.apache.org/jira/browse/IGNITE-12213 [2] https://issues.apache.org/jira/browse/IGNITE-11056 [3] https://issues.apache.org/jira/browse/IGNITE-11443 Best regards, Ivan Pavlukhin
Re: Mark MVCC with @IgniteExperimental
Note that someone uses it Main problem is a recovery process when persistence enabled and a cluster have more than one node. It is a problem even for regular transactional caches, the main difference - MVCC detects any inconsistencies while regular transactional caches may ignore it without any notification In other cases it works fine and provides promised guaranties. Of course there are several minor issues like performance ones, but there is a plan how to solve them (I could share it if anybody is curious) My opinion we should solve consistency issues first and finalize MVCC after that. Until that it’s OK to have it as experimental feature. Regards, Igor > 6 февр. 2020 г., в 21:25, Alexei Scherbakov > написал(а): > > I'm strongly support removal of MVCC from master. > > At the current state it bloats code base and should be reworked from > scratch using separate code base. > > чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev : > >> Hello! >> >> Please keep in mind that you need to create a separate proposal voting >> thread if you really like it to count. I wonder if Dmitry Pavlov can help >> us with the procedure. >> >> Otherwise, I think it makes total sense to restrict MVCC clusters to only >> have MVCC caches or REPLICATED TRANSACTIONAL caches (are they compatible in >> our current implementation) and no ATOMIC caches at all. >> >> Regards, >> -- >> Ilya Kasnacheev >> >> >> чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov : >> >>> Ilya, >>> >>> >>> 1. MVCC support requires code maintenance for other developed features >>> even if has not used and disabled. Currently, we've got an x2 level of >>> difficulty for implementation of new features. >>> >>> 2. It would be much easy to develop and support clusters with >>> mvcc-caches only rather than have a mixed configuration. With this >>> option we can dramatically reduce the amount of codebase removing from >>> mvcc-branch local, atomic, tx caches. >>> >>> >>> So, I'm +1 to remove it from the master branch and mark the current >>> API with @IgniteExperimental. >>> >>> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev >>> wrote: Hello! Why would we drop MVCC!? I can totally imagine a scenario where a large Ignite user surfaces >> with fixes for MVCC mode, if it is kept as an experimental feature. Then >> maybe it will graduate to beta some time in future. If it does too much strain on the TC, let's discuss that, but I don't remember problems with TC load lately, so maybe this is a moot point. Regards, -- Ilya Kasnacheev чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov : >> By the way, is there any reason to have this code in the master >>> branch > > I support removal MVCC from master. > > >> 6 февр. 2020 г., в 15:26, Andrey Gura >> написал(а): >> >> +1 >> >> By the way, is there any reason to have this code in the master >> branch? It seems feature is in unsupportable state and just wastes >> TC >> time and our effort to support MVCC related tests. >> >> On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk >> wrote: >>> >>> Agree, let's mark MVCC experimental. >>> >>> Stephen, the annotation serves as an additional >> documentation-style > marker. >>> For now there are no compile-time warnings when the API is used. >>> >>> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington < >>> stephen.darling...@gridgain.com>: >>> Yes! I’ve already seen people try to use this without awareness >>> that > it’s not production ready. What happens with the annotation, incidentally? Is it just in the documentation or do you get a compile-time warning? > On 6 Feb 2020, at 11:32, Nikolay Izhikov >>> wrote: > > Hello, Igniters. > > Should we mark MVCC feature with the new @IgniteExperimental? > > We explicitly note users that MVCC has beta status, for now [1] > >> Beta version of Transactional SQL and MVCC >> In Ignite v2.7, Transactional SQL and MVCC are released as beta versions to allow users to experiment and share feedback. >> This version of Transactional SQL and MVCC should not be >>> considered > for production. > > > [1] > https://apacheignite.readme.io/docs/multiversion-concurrency-control > > > > >>> >> > > > -- > > Best regards, > Alexei Scherbakov
Re: Mark MVCC with @IgniteExperimental
Hell, Alexey. > We should work on processes to prevent such merges in the future, but not > waste time reverting something that can be used for profit. Can you, please, clarify, what real-world use-cases for the current implementation of MVCC exists? > 7 февр. 2020 г., в 13:07, Alexey Goncharuk > написал(а): > > Not sure where we got the idea that MVCC code is useless in master. > > Alexei, > > I know that you used the MVCC partition counters implementation in order to > fix tx & atomic caches protocol issues. The MVCC WAL backpointer mechanics > can and should be used when we will move transaction records logging from > COMMITTING stage to PREPARING stage. Current cache entry versioning > mechanics can be used to allow faster reads inside transactions, direct > offheap scans and many other optimizations. > > We should work on processes to prevent such merges in the future, but not > waste time reverting something that can be used for profit.
Re: Mark MVCC with @IgniteExperimental
Not sure where we got the idea that MVCC code is useless in master. Alexei, I know that you used the MVCC partition counters implementation in order to fix tx & atomic caches protocol issues. The MVCC WAL backpointer mechanics can and should be used when we will move transaction records logging from COMMITTING stage to PREPARING stage. Current cache entry versioning mechanics can be used to allow faster reads inside transactions, direct offheap scans and many other optimizations. We should work on processes to prevent such merges in the future, but not waste time reverting something that can be used for profit.
Re: Mark MVCC with @IgniteExperimental
> 1. MVCC support requires code maintenance for other developed features > even if has not used and disabled. Currently, we've got an x2 level of > difficulty for implementation of new features. Maxim, I believe that not all features requires x2 level of implementation difficulty. Could you list here features which stumbled upon the MVCC? On Thu, Feb 6, 2020 at 7:41 PM Maxim Muzafarov wrote: > > Ilya, > > > 1. MVCC support requires code maintenance for other developed features > even if has not used and disabled. Currently, we've got an x2 level of > difficulty for implementation of new features. > > 2. It would be much easy to develop and support clusters with > mvcc-caches only rather than have a mixed configuration. With this > option we can dramatically reduce the amount of codebase removing from > mvcc-branch local, atomic, tx caches. > > > So, I'm +1 to remove it from the master branch and mark the current > API with @IgniteExperimental. > > On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev > wrote: > > > > Hello! > > > > Why would we drop MVCC!? > > > > I can totally imagine a scenario where a large Ignite user surfaces with > > fixes for MVCC mode, if it is kept as an experimental feature. Then maybe > > it will graduate to beta some time in future. > > > > If it does too much strain on the TC, let's discuss that, but I don't > > remember problems with TC load lately, so maybe this is a moot point. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov : > > > > > > By the way, is there any reason to have this code in the master branch > > > > > > I support removal MVCC from master. > > > > > > > > > > 6 февр. 2020 г., в 15:26, Andrey Gura написал(а): > > > > > > > > +1 > > > > > > > > By the way, is there any reason to have this code in the master > > > > branch? It seems feature is in unsupportable state and just wastes TC > > > > time and our effort to support MVCC related tests. > > > > > > > > On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk > > > > wrote: > > > >> > > > >> Agree, let's mark MVCC experimental. > > > >> > > > >> Stephen, the annotation serves as an additional documentation-style > > > marker. > > > >> For now there are no compile-time warnings when the API is used. > > > >> > > > >> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington < > > > >> stephen.darling...@gridgain.com>: > > > >> > > > >>> Yes! I’ve already seen people try to use this without awareness that > > > it’s > > > >>> not production ready. > > > >>> > > > >>> What happens with the annotation, incidentally? Is it just in the > > > >>> documentation or do you get a compile-time warning? > > > >>> > > > On 6 Feb 2020, at 11:32, Nikolay Izhikov wrote: > > > > > > Hello, Igniters. > > > > > > Should we mark MVCC feature with the new @IgniteExperimental? > > > > > > We explicitly note users that MVCC has beta status, for now [1] > > > > > > > Beta version of Transactional SQL and MVCC > > > > In Ignite v2.7, Transactional SQL and MVCC are released as beta > > > >>> versions to allow users to experiment and share feedback. > > > > This version of Transactional SQL and MVCC should not be considered > > > for > > > >>> production. > > > > > > > > > [1] > > > https://apacheignite.readme.io/docs/multiversion-concurrency-control > > > > > > > > > >>> > > > >>> > > > >>> > > > > > >
Re: Mark MVCC with @IgniteExperimental
Folks, Do not read between lines please. I didn't suggest MVCC removal. I asked, literally: is there any reason to have this code in the master? branch? Instead of listing reasons why we should support it I see posts like remove it from branch. Please, do not distort the meaning of the question. I agree with Ilya. Code change like this requires additional vote and I believe this vote will not pass with solution "remove it". On Thu, Feb 6, 2020 at 9:25 PM Alexei Scherbakov wrote: > > I'm strongly support removal of MVCC from master. > > At the current state it bloats code base and should be reworked from > scratch using separate code base. > > чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev : > > > Hello! > > > > Please keep in mind that you need to create a separate proposal voting > > thread if you really like it to count. I wonder if Dmitry Pavlov can help > > us with the procedure. > > > > Otherwise, I think it makes total sense to restrict MVCC clusters to only > > have MVCC caches or REPLICATED TRANSACTIONAL caches (are they compatible in > > our current implementation) and no ATOMIC caches at all. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov : > > > > > Ilya, > > > > > > > > > 1. MVCC support requires code maintenance for other developed features > > > even if has not used and disabled. Currently, we've got an x2 level of > > > difficulty for implementation of new features. > > > > > > 2. It would be much easy to develop and support clusters with > > > mvcc-caches only rather than have a mixed configuration. With this > > > option we can dramatically reduce the amount of codebase removing from > > > mvcc-branch local, atomic, tx caches. > > > > > > > > > So, I'm +1 to remove it from the master branch and mark the current > > > API with @IgniteExperimental. > > > > > > On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev > > > wrote: > > > > > > > > Hello! > > > > > > > > Why would we drop MVCC!? > > > > > > > > I can totally imagine a scenario where a large Ignite user surfaces > > with > > > > fixes for MVCC mode, if it is kept as an experimental feature. Then > > maybe > > > > it will graduate to beta some time in future. > > > > > > > > If it does too much strain on the TC, let's discuss that, but I don't > > > > remember problems with TC load lately, so maybe this is a moot point. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov : > > > > > > > > > > By the way, is there any reason to have this code in the master > > > branch > > > > > > > > > > I support removal MVCC from master. > > > > > > > > > > > > > > > > 6 февр. 2020 г., в 15:26, Andrey Gura > > написал(а): > > > > > > > > > > > > +1 > > > > > > > > > > > > By the way, is there any reason to have this code in the master > > > > > > branch? It seems feature is in unsupportable state and just wastes > > TC > > > > > > time and our effort to support MVCC related tests. > > > > > > > > > > > > On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk > > > > > > wrote: > > > > > >> > > > > > >> Agree, let's mark MVCC experimental. > > > > > >> > > > > > >> Stephen, the annotation serves as an additional > > documentation-style > > > > > marker. > > > > > >> For now there are no compile-time warnings when the API is used. > > > > > >> > > > > > >> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington < > > > > > >> stephen.darling...@gridgain.com>: > > > > > >> > > > > > >>> Yes! I’ve already seen people try to use this without awareness > > > that > > > > > it’s > > > > > >>> not production ready. > > > > > >>> > > > > > >>> What happens with the annotation, incidentally? Is it just in the > > > > > >>> documentation or do you get a compile-time warning? > > > > > >>> > > > > > On 6 Feb 2020, at 11:32, Nikolay Izhikov > > > wrote: > > > > > > > > > > Hello, Igniters. > > > > > > > > > > Should we mark MVCC feature with the new @IgniteExperimental? > > > > > > > > > > We explicitly note users that MVCC has beta status, for now [1] > > > > > > > > > > > Beta version of Transactional SQL and MVCC > > > > > > In Ignite v2.7, Transactional SQL and MVCC are released as beta > > > > > >>> versions to allow users to experiment and share feedback. > > > > > > This version of Transactional SQL and MVCC should not be > > > considered > > > > > for > > > > > >>> production. > > > > > > > > > > > > > > > [1] > > > > > https://apacheignite.readme.io/docs/multiversion-concurrency-control > > > > > > > > > > > > > > > >>> > > > > > >>> > > > > > >>> > > > > > > > > > > > > > > > > > > -- > > Best regards, > Alexei Scherbakov
[jira] [Created] (IGNITE-12638) Classes persisted by DistributedMetaStorage are not IgniteDTO
Ivan Bessonov created IGNITE-12638: -- Summary: Classes persisted by DistributedMetaStorage are not IgniteDTO Key: IGNITE-12638 URL: https://issues.apache.org/jira/browse/IGNITE-12638 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Ivan Bessonov Fix For: 2.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Update documentation about using Spring Data for Ignite
Hello! Please keep in mind that readme.io pages are suggest-editable. You can submit documentation changes at any time. Regards, -- Ilya Kasnacheev пт, 7 февр. 2020 г. в 12:01, Sergey Chernolyas : > Hi igniters! > > Feature, which I working on, requires to update the page > > https://apacheignite-mix.readme.io/docs/spring-data#section-apache-ignite-repository > . > Because the feature provides additional way to link Spring repository with > particular cache. > I think It is required additional example of code. > > -- > - > > With best regards, Sergey Chernolyas >
Re: Update documentation about using Spring Data for Ignite
Hi Sergey, Please create a ticket for documentation update as described in this section: https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Documentingaticket -Artem On 07.02.2020 12:00, Sergey Chernolyas wrote: Hi igniters! Feature, which I working on, requires to update the page https://apacheignite-mix.readme.io/docs/spring-data#section-apache-ignite-repository . Because the feature provides additional way to link Spring repository with particular cache. I think It is required additional example of code.
Update documentation about using Spring Data for Ignite
Hi igniters! Feature, which I working on, requires to update the page https://apacheignite-mix.readme.io/docs/spring-data#section-apache-ignite-repository . Because the feature provides additional way to link Spring repository with particular cache. I think It is required additional example of code. -- - With best regards, Sergey Chernolyas
Re: [DISCUSSION][IEP-39] Management API to cancel user provided tasks and queries.
Hello, Vyacheslav. > It seems to me we missed API that should be introduced into control utility. Do you think we should support control.sh for cancel tasks? > 7 февр. 2020 г., в 11:04, Alexey Goncharuk > написал(а): > > Alexei, > > I agree that there should be no principal difficulty with the unique ID for > each cancellable object, but I also see Nikolay's point about the wrong > copy-paste. > > I like minimalistic APIs, but in this case the price of a mistake may be > high. Let's let a wider circle of community members to speak out.
Re: Data vanished from cluster after INACTIVE/ACTIVE switch
> To prevent unexpected data loss on
deactivation CLI and JMX should require 'force' flag
Vladimir, please, go for it.
пт, 7 февр. 2020 г., 11:19 Vladimir Steshin :
> Ok. Then we are at the beginning. To prevent unexpected data loss on
> deactivation CLI and JMX should require 'force' flag. If there are no extra
> proposals I'm going to finish the pull request.
>
> чт, 6 февр. 2020 г. в 21:43, Alexei Scherbakov <
> alexey.scherbak...@gmail.com
> >:
>
> > Vladimir,
> >
> > IGNITE_REUSE_MEMORY_ON_DEACTIVATE doesn't prevent cache contents from
> > clearing.
> > It allows allocated memory reuse on re-activation to avoid OS specific
> > issues if allocated heap is rather large.
> >
> > You are right to create separate ticket for implementing required
> behavior.
> >
> > чт, 6 февр. 2020 г. в 16:37, Vladimir Steshin :
> >
> > > Or, is flag [1] is actual only for persistence mode? Related ticket [2]
> > is
> > > completely about disabled persistence.
> > > If previous assumption is right, I think, we can involve flag [1] in
> > ticket
> > > [2].
> > >
> > > [1]
> > >
> >
> org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE
> > > [2] https://issues.apache.org/jira/browse/IGNITE-12614
> > >
> > > чт, 6 февр. 2020 г. в 16:10, Vladimir Steshin :
> > >
> > > > Denis, Alexei,
> > > >
> > > > Regarding usage of flag
> > > >
> > >
> >
> org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE
> > > > [1]
> > > >
> > > > When enabled, I think the following test should work. But it fails.
> > > >
> > > > //
> > > > @Test
> > > > public void testDataPresent() throws Exception {
> > > > System.setProperty(IGNITE_REUSE_MEMORY_ON_DEACTIVATE,
> "true");
> > > >
> > > > IgniteEx i = startGrid(0);
> > > >
> > > > assertFalse(
> > > >
> > >
> >
> i.configuration().getDataStorageConfiguration().getDefaultDataRegionConfiguration()
> > > > .isPersistenceEnabled() );
> > > >
> > > > String name = "non-persistent-cache";
> > > >
> > > > i.createCache(name).put(1L, 1L);
> > > >
> > > > assertEquals(1L, i.cache(name).get(1L));
> > > >
> > > > i.cluster().state(ClusterState.INACTIVE);
> > > > i.cluster().state(ClusterState.ACTIVE);
> > > >
> > > > assertEquals(1L, i.cache(name).get(1L)); //Assertion error
> > here!
> > > > }
> > > > //
> > > >
> > > >
> > > > Several notes:
> > > >
> > > > - IgniteCacheDatabaseSharedManager#reuseMemory
> > > > is true
> > > > - IgniteCacheDatabaseSharedManager#onDeActivate(boolean shutdown)
> > > > is called with shutdown == false
> > > > - PageMemoryNoStoreImpl#stop(booleam deallocate)
> > > > is called with deallocate == false
> > > >
> > > > But the cache from the test still has zero size after reactivation.
> > > >
> > > > Is flag [1] disabled by default because it is not implemented /
> doesn't
> > > > work? Do we need to skip it in current ticket and rise new one?
> > > >
> > > > ср, 5 февр. 2020 г. в 21:05, Denis Magda :
> > > >
> > > >> I believe there might be a consistency-related reason why this flag
> > was
> > > >> disabled by default for caches that store data in Ignite native
> > > >> persistence. I hope, Alex Goncharuk or Scherbakov can shed some
> light
> > on
> > > >> this.
> > > >>
> > > >> As for the memory-only caches or caches backed up by a CacheStore
> such
> > > as
> > > >> an RDBMS, enabling of the flag should be harmless. Once we do this,
> > > we'll
> > > >> eliminate the need to load the data back into the cluster which can
> > be a
> > > >> time-consuming operation depending on the data volume.
> > > >>
> > > >>
> > > >> -
> > > >> Denis
> > > >>
> > > >>
> > > >> On Wed, Feb 5, 2020 at 11:58 AM Vladimir Steshin <
> vlads...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > Denis, but why reuse-data-on-deactivate was disabled by default?
> > There
> > > >> > should be a reason for that. Any data consistency issues when node
> > > gets
> > > >> > activated anew? We may use both solutions because the flag can be
> > > >> switched
> > > >> > off again.
> > > >> >
> > > >> > ср, 5 февр. 2020 г. в 20:47, Denis Magda :
> > > >> >
> > > >> > > Hi Vladimir,
> > > >> > >
> > > >> > > Yes, I'm suggesting us to enable this flag by
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE
> > > >> > > default instead of introducing --force flag and showing any
> > > warnings.
> > > >> > >
> > > >> > > -
> > > >> > > Denis
> > > >> > >
> > > >> > >
> > > >> > > On Wed, Feb 5, 2020 at 2:33 AM Vladimir Steshin <
> > vlads...@gmail.com
> > > >
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Hello all.
> > > >> > > >
> > > >> > > > Denis, which changes exactly? In current implementation of
> > ticket
> > > >> [2]
> > > >> >
Re: Data vanished from cluster after INACTIVE/ACTIVE switch
Ok. Then we are at the beginning. To prevent unexpected data loss on
deactivation CLI and JMX should require 'force' flag. If there are no extra
proposals I'm going to finish the pull request.
чт, 6 февр. 2020 г. в 21:43, Alexei Scherbakov :
> Vladimir,
>
> IGNITE_REUSE_MEMORY_ON_DEACTIVATE doesn't prevent cache contents from
> clearing.
> It allows allocated memory reuse on re-activation to avoid OS specific
> issues if allocated heap is rather large.
>
> You are right to create separate ticket for implementing required behavior.
>
> чт, 6 февр. 2020 г. в 16:37, Vladimir Steshin :
>
> > Or, is flag [1] is actual only for persistence mode? Related ticket [2]
> is
> > completely about disabled persistence.
> > If previous assumption is right, I think, we can involve flag [1] in
> ticket
> > [2].
> >
> > [1]
> >
> org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE
> > [2] https://issues.apache.org/jira/browse/IGNITE-12614
> >
> > чт, 6 февр. 2020 г. в 16:10, Vladimir Steshin :
> >
> > > Denis, Alexei,
> > >
> > > Regarding usage of flag
> > >
> >
> org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE
> > > [1]
> > >
> > > When enabled, I think the following test should work. But it fails.
> > >
> > > //
> > > @Test
> > > public void testDataPresent() throws Exception {
> > > System.setProperty(IGNITE_REUSE_MEMORY_ON_DEACTIVATE, "true");
> > >
> > > IgniteEx i = startGrid(0);
> > >
> > > assertFalse(
> > >
> >
> i.configuration().getDataStorageConfiguration().getDefaultDataRegionConfiguration()
> > > .isPersistenceEnabled() );
> > >
> > > String name = "non-persistent-cache";
> > >
> > > i.createCache(name).put(1L, 1L);
> > >
> > > assertEquals(1L, i.cache(name).get(1L));
> > >
> > > i.cluster().state(ClusterState.INACTIVE);
> > > i.cluster().state(ClusterState.ACTIVE);
> > >
> > > assertEquals(1L, i.cache(name).get(1L)); //Assertion error
> here!
> > > }
> > > //
> > >
> > >
> > > Several notes:
> > >
> > > - IgniteCacheDatabaseSharedManager#reuseMemory
> > > is true
> > > - IgniteCacheDatabaseSharedManager#onDeActivate(boolean shutdown)
> > > is called with shutdown == false
> > > - PageMemoryNoStoreImpl#stop(booleam deallocate)
> > > is called with deallocate == false
> > >
> > > But the cache from the test still has zero size after reactivation.
> > >
> > > Is flag [1] disabled by default because it is not implemented / doesn't
> > > work? Do we need to skip it in current ticket and rise new one?
> > >
> > > ср, 5 февр. 2020 г. в 21:05, Denis Magda :
> > >
> > >> I believe there might be a consistency-related reason why this flag
> was
> > >> disabled by default for caches that store data in Ignite native
> > >> persistence. I hope, Alex Goncharuk or Scherbakov can shed some light
> on
> > >> this.
> > >>
> > >> As for the memory-only caches or caches backed up by a CacheStore such
> > as
> > >> an RDBMS, enabling of the flag should be harmless. Once we do this,
> > we'll
> > >> eliminate the need to load the data back into the cluster which can
> be a
> > >> time-consuming operation depending on the data volume.
> > >>
> > >>
> > >> -
> > >> Denis
> > >>
> > >>
> > >> On Wed, Feb 5, 2020 at 11:58 AM Vladimir Steshin
> > >> wrote:
> > >>
> > >> > Denis, but why reuse-data-on-deactivate was disabled by default?
> There
> > >> > should be a reason for that. Any data consistency issues when node
> > gets
> > >> > activated anew? We may use both solutions because the flag can be
> > >> switched
> > >> > off again.
> > >> >
> > >> > ср, 5 февр. 2020 г. в 20:47, Denis Magda :
> > >> >
> > >> > > Hi Vladimir,
> > >> > >
> > >> > > Yes, I'm suggesting us to enable this flag by
> > >> > >
> > >> >
> > >>
> >
> org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE
> > >> > > default instead of introducing --force flag and showing any
> > warnings.
> > >> > >
> > >> > > -
> > >> > > Denis
> > >> > >
> > >> > >
> > >> > > On Wed, Feb 5, 2020 at 2:33 AM Vladimir Steshin <
> vlads...@gmail.com
> > >
> > >> > > wrote:
> > >> > >
> > >> > > > Hello all.
> > >> > > >
> > >> > > > Denis, which changes exactly? In current implementation of
> ticket
> > >> [2]
> > >> > > flag
> > >> > > > [1] is checked before requiring --force flag and showing any
> > >> warnings.
> > >> > Do
> > >> > > > we need to set reuse-memory-on-deactivate to true by default?
> > >> > > >
> > >> > > > [1]
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE
> > >> > > >
> > >> > > > [2] https://issues.apache.org/jira/browse/IGNITE-12614
> > >> > > >
> > >> > > >
> > >> > > > вт, 4 февр. 2020 г. в 22:45, Denis Magda :
> > >> > > >
> > >> > > > > That's
Re: Forbid mixed cache groups with both atomic and transactional caches
Nikolay, Ivan, Thank you guys! I knew that I should not worry =) Best regards, Ivan Pavlukhin ср, 5 февр. 2020 г. в 13:46, Ivan Rakov : > > Ivan, > > Thanks for pointing this out. Less than one day is indeed too early to > treat this discussion thread as a "community conclusion". Still, the > consensus among the current participants made me feel that a conclusion > will be reached. > We'll surely get back to the discussion if opposite opinions will arise. > > On Wed, Feb 5, 2020 at 1:11 PM Ivan Pavlukhin wrote: > > > Folks, > > > > A bit of offtop. Do we have some recommendations in the community how > > long should we wait until treating something as "a Community > > conclusion"? It worries me a little bit that I see a discussion for a > > first time and there is already a conclusion. And the discussion was > > started lesser than 24 hours ago. I suppose we should allow everyone > > interested to share an opinion (here I agree with the proposal) and it > > usually requires some time in open-source communities. > > > > ср, 5 февр. 2020 г. в 10:58, Ivan Rakov : > > > > > > Folks, > > > > > > Thanks for your feedback. > > > I've created a JIRA issue on this change: > > > https://issues.apache.org/jira/browse/IGNITE-12622 > > > > > > On Tue, Feb 4, 2020 at 10:43 PM Denis Magda wrote: > > > > > > > +1 from my end. It doesn't sound like a big deal if Ignite users need > > to > > > > define separate groups for atomic and transactional caches. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Tue, Feb 4, 2020 at 3:28 AM Ivan Rakov > > wrote: > > > > > > > > > Igniters, > > > > > > > > > > Apparently it's possible in Ignite to configure a cache group with > > both > > > > > ATOMIC and TRANSACTIONAL caches. > > > > > Proof: IgniteCacheGroupsTest#testContinuousQueriesMultipleGroups* > > tests. > > > > > In my opinion, it would be better to remove such possibility from the > > > > > product. There are several reasons: > > > > > > > > > > 1) The original idea of grouping caches was optimizing storage > > overhead > > > > and > > > > > PME time by joining data of similar caches into the same partitions. > > > > ATOMIC > > > > > and TRANSACTIONAL caches provide different guarantees and are > > designed > > > > for > > > > > different use cases, thus they can hardly be called "similar". > > > > > > > > > > 2) Diving deeper: synchronization protocols and possible reasons for > > > > > primary-backup divergences are conceptually different for ATOMIC and > > > > > TRANSACTIONAL cases. In TRANSACTIONAL case, transactions recovery > > > > protocol > > > > > allows to recover consistency if any participating node will fail, > > but > > > > for > > > > > ATOMIC caches there's possible scenario with failure of primary node > > > > where > > > > > neither of backups will contain the most recent state of the data. > > > > Example: > > > > > one backup have received updates 1, 3, 5 while another have received > > 2, 4 > > > > > (which is possible due to message reordering), and even tracking > > counters > > > > > [1] won't restore the consistency. The problem is that we can't > > > > distinguish > > > > > what kind of conflict we have faced in case update counters have > > diverged > > > > > in a mixed group. > > > > > > > > > > 3) Mixed groups are poorly tested. I can't find any tests except a > > couple > > > > > of smoke tests in IgniteCacheGroupsTest. We can't be sure that > > different > > > > > synchronization protocols will work correctly for such > > configurations, > > > > > especially under load and with a variety of dependent configuration > > > > > parameters. > > > > > > > > > > 4) I have never heard of any feedback on mixed groups. I have asked > > > > > different people on this and no one recalled any attempts to > > configure > > > > such > > > > > groups. I believe that in fact no one has ever tried to do it. > > > > > > > > > > Please let me know if you are aware of any cases where mixed groups > > are > > > > > used or reasons to keep them. Otherwise I'll create a ticket to > > prohibit > > > > > mixed configurations. > > > > > > > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-11797 > > > > > > > > > > -- > > > > > Best Regards, > > > > > Ivan Rakov > > > > > > > > > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > >
Re: [DISCUSSION] ignite-extension - ignite-spring-boot-autoconfigurer release.
Thanks for clarification. Igniters, I will proceed with the release in the next few days if there is no objections on it. > 7 февр. 2020 г., в 10:57, Ivan Pavlukhin написал(а): > > Hi Nikolay, > > In fact I did not mean anything supernatural. A scheme you mentioned >> I thought we just release module with the 1.0.0 version and specify >> supported Ignite version somewhere in the documentation. > sounds fine to me. > > Best regards, > Ivan Pavlukhin > > чт, 6 февр. 2020 г. в 15:00, Nikolay Izhikov : >> >> Hello, Ivan. >> >>> As usual we need to decide about versioning and a correspondence to Ignite >>> versions >>> As we are going to have a separate release cycle I can imagine an >>> independent versioning scheme with a range of supported Ignite versions. >> >> Please, clarify, what do you mean? >> Do you have any idea how it should be implemented? >> >> I thought we just release module with the 1.0.0 version and specify >> supported Ignite version somewhere in the documentation. >> >>> 6 февр. 2020 г., в 11:15, Ivan Pavlukhin написал(а): >>> >>> Nikolay, >>> >>> Thank you for driving it! It is great to establish this process in >>> practice earlier because it seems that we need to release a Flink >>> integration soon because Ignite 2.8 is going to be released without >>> that integration bundled. >>> >>> As usual we need to decide about versioning and a correspondence to >>> Ignite versions. As we are going to have a separate release cycle I >>> can imagine an independent versioning scheme with a range of supported >>> Ignite versions. >>> >>> Also I think it is a good idea to update ignite-extensions README on >>> GitHub and provide a link to relevant TC jobs. >>> >>> Best regards, >>> Ivan Pavlukhin >>> >>> ср, 5 февр. 2020 г. в 17:44, Denis Magda : Alex, did you have a chance to review Saikat’s changes related to the extensions repository organization and release approach? Denis On Wednesday, February 5, 2020, Nikolay Izhikov wrote: > Hello, Igniters. > > We don't have a release process for newly created ignite-extensions > modules. > I want to release two modules: > > * ignite-spring-boot-autoconfigure > * ignite-client-spring-boot-autoconfigure > > Let's discuss it. > > Any objections to it? > What should be done before release? > -- - Denis >>
Re: [DISCUSSION][IEP-39] Management API to cancel user provided tasks and queries.
Alexei, I agree that there should be no principal difficulty with the unique ID for each cancellable object, but I also see Nikolay's point about the wrong copy-paste. I like minimalistic APIs, but in this case the price of a mistake may be high. Let's let a wider circle of community members to speak out.
