Re: [PROPOSAL] Change approach to store checkpoint recovery data
Hello, Igniters! I've published benchmark results on the IEP page [1] Short summary: Storing recovery data on checkpoint can give performance boost (throughput) about 3-5%% in scenarios like IgnitePutBenchmark with default key range. In some extreme cases with heavy disk load it can provide even much better performance. But the downside is increased checkpoint duration up to 2x. Checkpoint buffer pages can't be released during recovery data write, it leads to excessive checkpoint buffer usage. High checkpoint buffer usage sooner enables throttling to protect from checkpoint buffer overflow. Also, there can be an issue with page replacement: if we can't find any page to replace except pages marked for checkpoint, we can replace such pages after the checkpoint marker is stored to disk. Previously, we waited for the marker's future to complete, but with the new approach there is a long time between checkpoint start and marker store event. So with the new approach we can come to OOM exceptions in cases when the old approach will wait a little time. In general, more precise tuning of data regions is required with the new approach. So, I propose to include this feature as experimental and disabled by default for at least one release. [1]: https://cwiki.apache.org/confluence/display/IGNITE/IEP-113+Change+approach+to+store+checkpoint+recovery+data чт, 9 нояб. 2023 г. в 20:05, Anton Vinogradov : > > Alex, agree to the proposal. > > On Thu, Nov 9, 2023 at 5:31 PM Alex Plehanov > wrote: > > > Anton, > > > > Async physical logging is a target and most promising solution. > > > > In this scenario: > > 1. Implement logical and physical records split. > > 2. Implement async physical logging (actually, already implemented as PoC). > > 3. Drop solution, implemented in (1) after some time, if solution, > > implemented in (2) has no critical issues. > > We do some useless job, which we assume will be dropped soon. > > > > Instead, I propose: > > 1. Implement async physical logging > > 2. Drop old physical logging implementation if (1) has no critical > > issues after some time. > > 3. Or implement logical and physical records split, if critical issues > > found in (1). > > In this case, we proceed to the alternative approach only if the main > > approach fails. > > > > чт, 9 нояб. 2023 г. в 13:18, Anton Vinogradov : > > > > > > In this case, we can split logs to logical and physical at the initial > > fix. > > > This should not cause any negative side effects. > > > And, then implement an async physical logging as an alternative solution? > > > > > > On Thu, Nov 9, 2023 at 12:52 PM Alex Plehanov > > > wrote: > > > > > > > Anton, > > > > > > > > My concern is not only about compatibility. The new recovery data > > > > storing approach is not a silver bullet, it has drawbacks as well. > > > > Also, we can't be sure that the new approach is applicable for all > > > > environments: increased checkpoint time can lead to throttling or even > > > > OOM in some cases. So, in my opinion, it's better to keep both > > > > approaches and allow users to configure it. We should keep both > > > > approaches at least for a one release after the new approach will be > > > > enabled by default. In case of a critical problem users can raise the > > > > issue and switch to the old approach. > > > > > > > > пт, 3 нояб. 2023 г. в 16:33, Anton Vinogradov : > > > > > > > > > > Sounds good to me, except the compatibility proposal. > > > > > No need to keep the old behaviour. Noone will update the node after > > the > > > > > crash. > > > > > Update must happen only after the plain node stop, let's just check > > this > > > > > instead of groving the code complexity. > > > > > > > > > > On Thu, Nov 2, 2023 at 4:55 PM Alex Plehanov < > > plehanov.a...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hello, Igniters! > > > > > > > > > > > > I'd like to discuss the way of storing checkpoint recovery data. > > > > > > Now, we are writing extra data to WAL files to protect from > > failures > > > > > > during checkpoints. Later, we read and write WAL files with this > > extra > > > > > > data a couple of times, causing excessive disk load, which can > > lead to > > > > > > performance drop. > > > > > > We can try to improve this by changin
Re: [PROPOSAL] Change approach to store checkpoint recovery data
Alex, agree to the proposal. On Thu, Nov 9, 2023 at 5:31 PM Alex Plehanov wrote: > Anton, > > Async physical logging is a target and most promising solution. > > In this scenario: > 1. Implement logical and physical records split. > 2. Implement async physical logging (actually, already implemented as PoC). > 3. Drop solution, implemented in (1) after some time, if solution, > implemented in (2) has no critical issues. > We do some useless job, which we assume will be dropped soon. > > Instead, I propose: > 1. Implement async physical logging > 2. Drop old physical logging implementation if (1) has no critical > issues after some time. > 3. Or implement logical and physical records split, if critical issues > found in (1). > In this case, we proceed to the alternative approach only if the main > approach fails. > > чт, 9 нояб. 2023 г. в 13:18, Anton Vinogradov : > > > > In this case, we can split logs to logical and physical at the initial > fix. > > This should not cause any negative side effects. > > And, then implement an async physical logging as an alternative solution? > > > > On Thu, Nov 9, 2023 at 12:52 PM Alex Plehanov > > wrote: > > > > > Anton, > > > > > > My concern is not only about compatibility. The new recovery data > > > storing approach is not a silver bullet, it has drawbacks as well. > > > Also, we can't be sure that the new approach is applicable for all > > > environments: increased checkpoint time can lead to throttling or even > > > OOM in some cases. So, in my opinion, it's better to keep both > > > approaches and allow users to configure it. We should keep both > > > approaches at least for a one release after the new approach will be > > > enabled by default. In case of a critical problem users can raise the > > > issue and switch to the old approach. > > > > > > пт, 3 нояб. 2023 г. в 16:33, Anton Vinogradov : > > > > > > > > Sounds good to me, except the compatibility proposal. > > > > No need to keep the old behaviour. Noone will update the node after > the > > > > crash. > > > > Update must happen only after the plain node stop, let's just check > this > > > > instead of groving the code complexity. > > > > > > > > On Thu, Nov 2, 2023 at 4:55 PM Alex Plehanov < > plehanov.a...@gmail.com> > > > > wrote: > > > > > > > > > Hello, Igniters! > > > > > > > > > > I'd like to discuss the way of storing checkpoint recovery data. > > > > > Now, we are writing extra data to WAL files to protect from > failures > > > > > during checkpoints. Later, we read and write WAL files with this > extra > > > > > data a couple of times, causing excessive disk load, which can > lead to > > > > > performance drop. > > > > > We can try to improve this by changing the approach for storing > > > > > checkpoint recovery data. I've prepared the IEP [1] with my > proposals. > > > > > The main idea - move checkpoint recovery data from WAL physical > > > > > records to some file written right before the checkpoint. Please > have > > > > > a look at IEP for more information. > > > > > I've implemented PoC [2] for the described ideas. We will benchmark > > > > > this PoC soon and I will share the results. > > > > > > > > > > WDYT about this proposal? > > > > > > > > > > [1]: > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-113+Change+approach+to+store+checkpoint+recovery+data > > > > > [2]: https://github.com/apache/ignite/pull/11024/files > > > > > > > > >
Re: [PROPOSAL] Change approach to store checkpoint recovery data
Anton, Async physical logging is a target and most promising solution. In this scenario: 1. Implement logical and physical records split. 2. Implement async physical logging (actually, already implemented as PoC). 3. Drop solution, implemented in (1) after some time, if solution, implemented in (2) has no critical issues. We do some useless job, which we assume will be dropped soon. Instead, I propose: 1. Implement async physical logging 2. Drop old physical logging implementation if (1) has no critical issues after some time. 3. Or implement logical and physical records split, if critical issues found in (1). In this case, we proceed to the alternative approach only if the main approach fails. чт, 9 нояб. 2023 г. в 13:18, Anton Vinogradov : > > In this case, we can split logs to logical and physical at the initial fix. > This should not cause any negative side effects. > And, then implement an async physical logging as an alternative solution? > > On Thu, Nov 9, 2023 at 12:52 PM Alex Plehanov > wrote: > > > Anton, > > > > My concern is not only about compatibility. The new recovery data > > storing approach is not a silver bullet, it has drawbacks as well. > > Also, we can't be sure that the new approach is applicable for all > > environments: increased checkpoint time can lead to throttling or even > > OOM in some cases. So, in my opinion, it's better to keep both > > approaches and allow users to configure it. We should keep both > > approaches at least for a one release after the new approach will be > > enabled by default. In case of a critical problem users can raise the > > issue and switch to the old approach. > > > > пт, 3 нояб. 2023 г. в 16:33, Anton Vinogradov : > > > > > > Sounds good to me, except the compatibility proposal. > > > No need to keep the old behaviour. Noone will update the node after the > > > crash. > > > Update must happen only after the plain node stop, let's just check this > > > instead of groving the code complexity. > > > > > > On Thu, Nov 2, 2023 at 4:55 PM Alex Plehanov > > > wrote: > > > > > > > Hello, Igniters! > > > > > > > > I'd like to discuss the way of storing checkpoint recovery data. > > > > Now, we are writing extra data to WAL files to protect from failures > > > > during checkpoints. Later, we read and write WAL files with this extra > > > > data a couple of times, causing excessive disk load, which can lead to > > > > performance drop. > > > > We can try to improve this by changing the approach for storing > > > > checkpoint recovery data. I've prepared the IEP [1] with my proposals. > > > > The main idea - move checkpoint recovery data from WAL physical > > > > records to some file written right before the checkpoint. Please have > > > > a look at IEP for more information. > > > > I've implemented PoC [2] for the described ideas. We will benchmark > > > > this PoC soon and I will share the results. > > > > > > > > WDYT about this proposal? > > > > > > > > [1]: > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-113+Change+approach+to+store+checkpoint+recovery+data > > > > [2]: https://github.com/apache/ignite/pull/11024/files > > > > > >
Re: [PROPOSAL] Change approach to store checkpoint recovery data
In this case, we can split logs to logical and physical at the initial fix. This should not cause any negative side effects. And, then implement an async physical logging as an alternative solution? On Thu, Nov 9, 2023 at 12:52 PM Alex Plehanov wrote: > Anton, > > My concern is not only about compatibility. The new recovery data > storing approach is not a silver bullet, it has drawbacks as well. > Also, we can't be sure that the new approach is applicable for all > environments: increased checkpoint time can lead to throttling or even > OOM in some cases. So, in my opinion, it's better to keep both > approaches and allow users to configure it. We should keep both > approaches at least for a one release after the new approach will be > enabled by default. In case of a critical problem users can raise the > issue and switch to the old approach. > > пт, 3 нояб. 2023 г. в 16:33, Anton Vinogradov : > > > > Sounds good to me, except the compatibility proposal. > > No need to keep the old behaviour. Noone will update the node after the > > crash. > > Update must happen only after the plain node stop, let's just check this > > instead of groving the code complexity. > > > > On Thu, Nov 2, 2023 at 4:55 PM Alex Plehanov > > wrote: > > > > > Hello, Igniters! > > > > > > I'd like to discuss the way of storing checkpoint recovery data. > > > Now, we are writing extra data to WAL files to protect from failures > > > during checkpoints. Later, we read and write WAL files with this extra > > > data a couple of times, causing excessive disk load, which can lead to > > > performance drop. > > > We can try to improve this by changing the approach for storing > > > checkpoint recovery data. I've prepared the IEP [1] with my proposals. > > > The main idea - move checkpoint recovery data from WAL physical > > > records to some file written right before the checkpoint. Please have > > > a look at IEP for more information. > > > I've implemented PoC [2] for the described ideas. We will benchmark > > > this PoC soon and I will share the results. > > > > > > WDYT about this proposal? > > > > > > [1]: > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-113+Change+approach+to+store+checkpoint+recovery+data > > > [2]: https://github.com/apache/ignite/pull/11024/files > > > >
Re: [PROPOSAL] Change approach to store checkpoint recovery data
Anton, My concern is not only about compatibility. The new recovery data storing approach is not a silver bullet, it has drawbacks as well. Also, we can't be sure that the new approach is applicable for all environments: increased checkpoint time can lead to throttling or even OOM in some cases. So, in my opinion, it's better to keep both approaches and allow users to configure it. We should keep both approaches at least for a one release after the new approach will be enabled by default. In case of a critical problem users can raise the issue and switch to the old approach. пт, 3 нояб. 2023 г. в 16:33, Anton Vinogradov : > > Sounds good to me, except the compatibility proposal. > No need to keep the old behaviour. Noone will update the node after the > crash. > Update must happen only after the plain node stop, let's just check this > instead of groving the code complexity. > > On Thu, Nov 2, 2023 at 4:55 PM Alex Plehanov > wrote: > > > Hello, Igniters! > > > > I'd like to discuss the way of storing checkpoint recovery data. > > Now, we are writing extra data to WAL files to protect from failures > > during checkpoints. Later, we read and write WAL files with this extra > > data a couple of times, causing excessive disk load, which can lead to > > performance drop. > > We can try to improve this by changing the approach for storing > > checkpoint recovery data. I've prepared the IEP [1] with my proposals. > > The main idea - move checkpoint recovery data from WAL physical > > records to some file written right before the checkpoint. Please have > > a look at IEP for more information. > > I've implemented PoC [2] for the described ideas. We will benchmark > > this PoC soon and I will share the results. > > > > WDYT about this proposal? > > > > [1]: > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-113+Change+approach+to+store+checkpoint+recovery+data > > [2]: https://github.com/apache/ignite/pull/11024/files > >
Re: [PROPOSAL] Change approach to store checkpoint recovery data
Sounds good to me, except the compatibility proposal. No need to keep the old behaviour. Noone will update the node after the crash. Update must happen only after the plain node stop, let's just check this instead of groving the code complexity. On Thu, Nov 2, 2023 at 4:55 PM Alex Plehanov wrote: > Hello, Igniters! > > I'd like to discuss the way of storing checkpoint recovery data. > Now, we are writing extra data to WAL files to protect from failures > during checkpoints. Later, we read and write WAL files with this extra > data a couple of times, causing excessive disk load, which can lead to > performance drop. > We can try to improve this by changing the approach for storing > checkpoint recovery data. I've prepared the IEP [1] with my proposals. > The main idea - move checkpoint recovery data from WAL physical > records to some file written right before the checkpoint. Please have > a look at IEP for more information. > I've implemented PoC [2] for the described ideas. We will benchmark > this PoC soon and I will share the results. > > WDYT about this proposal? > > [1]: > https://cwiki.apache.org/confluence/display/IGNITE/IEP-113+Change+approach+to+store+checkpoint+recovery+data > [2]: https://github.com/apache/ignite/pull/11024/files >
[PROPOSAL] Change approach to store checkpoint recovery data
Hello, Igniters! I'd like to discuss the way of storing checkpoint recovery data. Now, we are writing extra data to WAL files to protect from failures during checkpoints. Later, we read and write WAL files with this extra data a couple of times, causing excessive disk load, which can lead to performance drop. We can try to improve this by changing the approach for storing checkpoint recovery data. I've prepared the IEP [1] with my proposals. The main idea - move checkpoint recovery data from WAL physical records to some file written right before the checkpoint. Please have a look at IEP for more information. I've implemented PoC [2] for the described ideas. We will benchmark this PoC soon and I will share the results. WDYT about this proposal? [1]: https://cwiki.apache.org/confluence/display/IGNITE/IEP-113+Change+approach+to+store+checkpoint+recovery+data [2]: https://github.com/apache/ignite/pull/11024/files
Re: [PROPOSAL] Move Ignite 2.x to JDK11 compilation
+1 > 24 окт. 2023 г., в 19:25, Anton Vinogradov написал(а): > > ++1 for switch to the OpenJDK framework > > As to original question, I propose to (step-by-step): > 1) Switch to java 11 testing instead of 8 > 2) Fix java 11 release > 3) Switch to maven.compiler.source 11 (Vote required) > > On Tue, Oct 24, 2023 at 7:12 PM Dmitriy Pavlov wrote: > >> ++1 for testing using JDK11 >> >> +0 for switching off support of JDK8 runtimes and class version (unless >> compilation using JDK11 is done with -target=1.8 our users won't be able to >> run Ignite using Java 8). >> >> I suggest the following next steps: once tests are completely fine on >> Teamcity using JDK 11, we start a separate thread named like: >> "[VOTE] discontinuing JDK 8 since the 2.16 release" >> to make the issue for end users more obvious. Since Nikita volunteers to be >> a Release Manager, I suppose that 2.16 will be released quite soon. >> >> I personally prefer to switch to newer Java. Using newer runtime helps us >> to provide speed and scale, since JVM is developed all the time. But I >> might be unaware of the risks, so let's discuss it later with the entire >> dev community. >> >> Sincerely, >> Dmitriy Pavlov >> >> ср, 30 авг. 2023 г. в 19:09, Ivan Daschinsky : >> >>> +1, sounds reasonable for the open source project. IMHO, Eclipse Temurin >>> JDK is a rule of thumb choice nowadays. >>> >>> ср, 30 авг. 2023 г. в 18:40, Peter Ivanov : >>> >>>> Hi, Igniters! >>>> >>>> As part of this proposal I would also like to discuss the JDK vendors >> we >>>> are using on our CI platforms TeamCIty. >>>> Historically, Ignite 2.x is being built under Oracle's edition - mostly >>>> because of some features like JFR or similar. >>>> However today we have pretty much solid alternative represented by >>> OpenJDK >>>> and its most popular build Eclipse Temurin, which provides every >> required >>>> version for our needs (and especially LTS versions 1.8, 11 and 17) with >>> all >>>> necessary updates. >>>> >>>> So, I suggest we update our build agents for TeamCity accordingly, >>> provide >>>> OpenJDK framework for those 3 major versions and discontinue Oracle's >>>> builds. >>>> WDYT? >>>> >>>> пт, 25 авг. 2023 г. в 12:13, Ivan Daschinsky : >>>> >>>>> +1. It's time to do it at last. >>>>> >>>>> пт, 25 авг. 2023 г. в 12:06, Peter Ivanov : >>>>> >>>>>> Mostly, yes. >>>>>> >>>>>> In other words - proposal is about starting shipping Apache Ignite >>>>> releases >>>>>> with JDK11 compiled binaries thus dropping JDK8-10 runtime support. >>>>>> >>>>>> пт, 25 авг. 2023 г. в 12:03, Anton Vinogradov : >>>>>> >>>>>>> I looks like you're proposing not migration to 2.11 (because it >> is >>>>>> already >>>>>>> supported), but Java 8-9 support dropping. >>>>>>> >>>>>>> On Fri, Aug 25, 2023 at 11:54 AM Peter Ivanov < >> vvei...@apache.org> >>>>>> wrote: >>>>>>> >>>>>>>> Hi, Igniters! >>>>>>>> >>>>>>>> >>>>>>>> I would like to propose the next, if you don't mind me saying, >>>>>>>> revolutionary step forward in our project: moving Ignite 2.x >>>>>> compilation >>>>>>> to >>>>>>>> JDK11 minimum version. >>>>>>>> I'd rather not make arguments, pros and cons other that >> currently >>>>> exist >>>>>>> in >>>>>>>> Java world - you know them better than me. Let's just say that >> it >>>>> seems >>>>>>>> that time has come - consider at least that JDK11 as the LTS >>>> version >>>>> is >>>>>>>> already about 4 and a half years on the go, and Ignite 3.x >>> started >>>>> from >>>>>>>> JDK11 right away. >>>>>>>> >>>>>>>> This change may possibly require from us additional efforts on >>>>>> supporting >>>>>>>> the last version with JDK8 in terms of releasing additional >>> patches >>>>> and >>>>>>>> hotfixes a bit longer than usual. However, this is up to the >>>>> community >>>>>> to >>>>>>>> decide. >>>>>>>> >>>>>>>> Currently, Apache Ignite 2.x (with Extensions as well) is >> already >>>>>>> prepared >>>>>>>> for being compiled with JDK11 and almost all tests are passing. >>> If >>>> we >>>>>>> come >>>>>>>> to an agreement about this proposal and designate the next >>> version >>>>> that >>>>>>>> will become the first to provide JDK11 compiled binaries - I am >>>> ready >>>>>> to >>>>>>>> start the process of updating the TeamCity building project >>>>>> accordingly. >>>>>>>> >>>>>>>> >>>>>>>> Please, share your thoughts. >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Sincerely yours, Ivan Daschinskiy >>>>> >>>> >>> >>> >>> -- >>> Sincerely yours, Ivan Daschinskiy >>> >>
Re: [PROPOSAL] Move Ignite 2.x to JDK11 compilation
++1 for switch to the OpenJDK framework As to original question, I propose to (step-by-step): 1) Switch to java 11 testing instead of 8 2) Fix java 11 release 3) Switch to maven.compiler.source 11 (Vote required) On Tue, Oct 24, 2023 at 7:12 PM Dmitriy Pavlov wrote: > ++1 for testing using JDK11 > > +0 for switching off support of JDK8 runtimes and class version (unless > compilation using JDK11 is done with -target=1.8 our users won't be able to > run Ignite using Java 8). > > I suggest the following next steps: once tests are completely fine on > Teamcity using JDK 11, we start a separate thread named like: > "[VOTE] discontinuing JDK 8 since the 2.16 release" > to make the issue for end users more obvious. Since Nikita volunteers to be > a Release Manager, I suppose that 2.16 will be released quite soon. > > I personally prefer to switch to newer Java. Using newer runtime helps us > to provide speed and scale, since JVM is developed all the time. But I > might be unaware of the risks, so let's discuss it later with the entire > dev community. > > Sincerely, > Dmitriy Pavlov > > ср, 30 авг. 2023 г. в 19:09, Ivan Daschinsky : > > > +1, sounds reasonable for the open source project. IMHO, Eclipse Temurin > > JDK is a rule of thumb choice nowadays. > > > > ср, 30 авг. 2023 г. в 18:40, Peter Ivanov : > > > > > Hi, Igniters! > > > > > > As part of this proposal I would also like to discuss the JDK vendors > we > > > are using on our CI platforms TeamCIty. > > > Historically, Ignite 2.x is being built under Oracle's edition - mostly > > > because of some features like JFR or similar. > > > However today we have pretty much solid alternative represented by > > OpenJDK > > > and its most popular build Eclipse Temurin, which provides every > required > > > version for our needs (and especially LTS versions 1.8, 11 and 17) with > > all > > > necessary updates. > > > > > > So, I suggest we update our build agents for TeamCity accordingly, > > provide > > > OpenJDK framework for those 3 major versions and discontinue Oracle's > > > builds. > > > WDYT? > > > > > > пт, 25 авг. 2023 г. в 12:13, Ivan Daschinsky : > > > > > > > +1. It's time to do it at last. > > > > > > > > пт, 25 авг. 2023 г. в 12:06, Peter Ivanov : > > > > > > > > > Mostly, yes. > > > > > > > > > > In other words - proposal is about starting shipping Apache Ignite > > > > releases > > > > > with JDK11 compiled binaries thus dropping JDK8-10 runtime support. > > > > > > > > > > пт, 25 авг. 2023 г. в 12:03, Anton Vinogradov : > > > > > > > > > > > I looks like you're proposing not migration to 2.11 (because it > is > > > > > already > > > > > > supported), but Java 8-9 support dropping. > > > > > > > > > > > > On Fri, Aug 25, 2023 at 11:54 AM Peter Ivanov < > vvei...@apache.org> > > > > > wrote: > > > > > > > > > > > > > Hi, Igniters! > > > > > > > > > > > > > > > > > > > > > I would like to propose the next, if you don't mind me saying, > > > > > > > revolutionary step forward in our project: moving Ignite 2.x > > > > > compilation > > > > > > to > > > > > > > JDK11 minimum version. > > > > > > > I'd rather not make arguments, pros and cons other that > currently > > > > exist > > > > > > in > > > > > > > Java world - you know them better than me. Let's just say that > it > > > > seems > > > > > > > that time has come - consider at least that JDK11 as the LTS > > > version > > > > is > > > > > > > already about 4 and a half years on the go, and Ignite 3.x > > started > > > > from > > > > > > > JDK11 right away. > > > > > > > > > > > > > > This change may possibly require from us additional efforts on > > > > > supporting > > > > > > > the last version with JDK8 in terms of releasing additional > > patches > > > > and > > > > > > > hotfixes a bit longer than usual. However, this is up to the > > > > community > > > > > to > > > > > > > decide. > > > > > > > > > > > > > > Currently, Apache Ignite 2.x (with Extensions as well) is > already > > > > > > prepared > > > > > > > for being compiled with JDK11 and almost all tests are passing. > > If > > > we > > > > > > come > > > > > > > to an agreement about this proposal and designate the next > > version > > > > that > > > > > > > will become the first to provide JDK11 compiled binaries - I am > > > ready > > > > > to > > > > > > > start the process of updating the TeamCity building project > > > > > accordingly. > > > > > > > > > > > > > > > > > > > > > Please, share your thoughts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Sincerely yours, Ivan Daschinskiy > > > > > > > > > > > > > -- > > Sincerely yours, Ivan Daschinskiy > > >
Re: [PROPOSAL] Move Ignite 2.x to JDK11 compilation
++1 for testing using JDK11 +0 for switching off support of JDK8 runtimes and class version (unless compilation using JDK11 is done with -target=1.8 our users won't be able to run Ignite using Java 8). I suggest the following next steps: once tests are completely fine on Teamcity using JDK 11, we start a separate thread named like: "[VOTE] discontinuing JDK 8 since the 2.16 release" to make the issue for end users more obvious. Since Nikita volunteers to be a Release Manager, I suppose that 2.16 will be released quite soon. I personally prefer to switch to newer Java. Using newer runtime helps us to provide speed and scale, since JVM is developed all the time. But I might be unaware of the risks, so let's discuss it later with the entire dev community. Sincerely, Dmitriy Pavlov ср, 30 авг. 2023 г. в 19:09, Ivan Daschinsky : > +1, sounds reasonable for the open source project. IMHO, Eclipse Temurin > JDK is a rule of thumb choice nowadays. > > ср, 30 авг. 2023 г. в 18:40, Peter Ivanov : > > > Hi, Igniters! > > > > As part of this proposal I would also like to discuss the JDK vendors we > > are using on our CI platforms TeamCIty. > > Historically, Ignite 2.x is being built under Oracle's edition - mostly > > because of some features like JFR or similar. > > However today we have pretty much solid alternative represented by > OpenJDK > > and its most popular build Eclipse Temurin, which provides every required > > version for our needs (and especially LTS versions 1.8, 11 and 17) with > all > > necessary updates. > > > > So, I suggest we update our build agents for TeamCity accordingly, > provide > > OpenJDK framework for those 3 major versions and discontinue Oracle's > > builds. > > WDYT? > > > > пт, 25 авг. 2023 г. в 12:13, Ivan Daschinsky : > > > > > +1. It's time to do it at last. > > > > > > пт, 25 авг. 2023 г. в 12:06, Peter Ivanov : > > > > > > > Mostly, yes. > > > > > > > > In other words - proposal is about starting shipping Apache Ignite > > > releases > > > > with JDK11 compiled binaries thus dropping JDK8-10 runtime support. > > > > > > > > пт, 25 авг. 2023 г. в 12:03, Anton Vinogradov : > > > > > > > > > I looks like you're proposing not migration to 2.11 (because it is > > > > already > > > > > supported), but Java 8-9 support dropping. > > > > > > > > > > On Fri, Aug 25, 2023 at 11:54 AM Peter Ivanov > > > > wrote: > > > > > > > > > > > Hi, Igniters! > > > > > > > > > > > > > > > > > > I would like to propose the next, if you don't mind me saying, > > > > > > revolutionary step forward in our project: moving Ignite 2.x > > > > compilation > > > > > to > > > > > > JDK11 minimum version. > > > > > > I'd rather not make arguments, pros and cons other that currently > > > exist > > > > > in > > > > > > Java world - you know them better than me. Let's just say that it > > > seems > > > > > > that time has come - consider at least that JDK11 as the LTS > > version > > > is > > > > > > already about 4 and a half years on the go, and Ignite 3.x > started > > > from > > > > > > JDK11 right away. > > > > > > > > > > > > This change may possibly require from us additional efforts on > > > > supporting > > > > > > the last version with JDK8 in terms of releasing additional > patches > > > and > > > > > > hotfixes a bit longer than usual. However, this is up to the > > > community > > > > to > > > > > > decide. > > > > > > > > > > > > Currently, Apache Ignite 2.x (with Extensions as well) is already > > > > > prepared > > > > > > for being compiled with JDK11 and almost all tests are passing. > If > > we > > > > > come > > > > > > to an agreement about this proposal and designate the next > version > > > that > > > > > > will become the first to provide JDK11 compiled binaries - I am > > ready > > > > to > > > > > > start the process of updating the TeamCity building project > > > > accordingly. > > > > > > > > > > > > > > > > > > Please, share your thoughts. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Sincerely yours, Ivan Daschinskiy > > > > > > > > -- > Sincerely yours, Ivan Daschinskiy >
Re: [PROPOSAL] Move Ignite 2.x to JDK11 compilation
+1, sounds reasonable for the open source project. IMHO, Eclipse Temurin JDK is a rule of thumb choice nowadays. ср, 30 авг. 2023 г. в 18:40, Peter Ivanov : > Hi, Igniters! > > As part of this proposal I would also like to discuss the JDK vendors we > are using on our CI platforms TeamCIty. > Historically, Ignite 2.x is being built under Oracle's edition - mostly > because of some features like JFR or similar. > However today we have pretty much solid alternative represented by OpenJDK > and its most popular build Eclipse Temurin, which provides every required > version for our needs (and especially LTS versions 1.8, 11 and 17) with all > necessary updates. > > So, I suggest we update our build agents for TeamCity accordingly, provide > OpenJDK framework for those 3 major versions and discontinue Oracle's > builds. > WDYT? > > пт, 25 авг. 2023 г. в 12:13, Ivan Daschinsky : > > > +1. It's time to do it at last. > > > > пт, 25 авг. 2023 г. в 12:06, Peter Ivanov : > > > > > Mostly, yes. > > > > > > In other words - proposal is about starting shipping Apache Ignite > > releases > > > with JDK11 compiled binaries thus dropping JDK8-10 runtime support. > > > > > > пт, 25 авг. 2023 г. в 12:03, Anton Vinogradov : > > > > > > > I looks like you're proposing not migration to 2.11 (because it is > > > already > > > > supported), but Java 8-9 support dropping. > > > > > > > > On Fri, Aug 25, 2023 at 11:54 AM Peter Ivanov > > > wrote: > > > > > > > > > Hi, Igniters! > > > > > > > > > > > > > > > I would like to propose the next, if you don't mind me saying, > > > > > revolutionary step forward in our project: moving Ignite 2.x > > > compilation > > > > to > > > > > JDK11 minimum version. > > > > > I'd rather not make arguments, pros and cons other that currently > > exist > > > > in > > > > > Java world - you know them better than me. Let's just say that it > > seems > > > > > that time has come - consider at least that JDK11 as the LTS > version > > is > > > > > already about 4 and a half years on the go, and Ignite 3.x started > > from > > > > > JDK11 right away. > > > > > > > > > > This change may possibly require from us additional efforts on > > > supporting > > > > > the last version with JDK8 in terms of releasing additional patches > > and > > > > > hotfixes a bit longer than usual. However, this is up to the > > community > > > to > > > > > decide. > > > > > > > > > > Currently, Apache Ignite 2.x (with Extensions as well) is already > > > > prepared > > > > > for being compiled with JDK11 and almost all tests are passing. If > we > > > > come > > > > > to an agreement about this proposal and designate the next version > > that > > > > > will become the first to provide JDK11 compiled binaries - I am > ready > > > to > > > > > start the process of updating the TeamCity building project > > > accordingly. > > > > > > > > > > > > > > > Please, share your thoughts. > > > > > > > > > > > > > > > > > > -- > > Sincerely yours, Ivan Daschinskiy > > > -- Sincerely yours, Ivan Daschinskiy
Re: [PROPOSAL] Move Ignite 2.x to JDK11 compilation
Hi, Igniters! As part of this proposal I would also like to discuss the JDK vendors we are using on our CI platforms TeamCIty. Historically, Ignite 2.x is being built under Oracle's edition - mostly because of some features like JFR or similar. However today we have pretty much solid alternative represented by OpenJDK and its most popular build Eclipse Temurin, which provides every required version for our needs (and especially LTS versions 1.8, 11 and 17) with all necessary updates. So, I suggest we update our build agents for TeamCity accordingly, provide OpenJDK framework for those 3 major versions and discontinue Oracle's builds. WDYT? пт, 25 авг. 2023 г. в 12:13, Ivan Daschinsky : > +1. It's time to do it at last. > > пт, 25 авг. 2023 г. в 12:06, Peter Ivanov : > > > Mostly, yes. > > > > In other words - proposal is about starting shipping Apache Ignite > releases > > with JDK11 compiled binaries thus dropping JDK8-10 runtime support. > > > > пт, 25 авг. 2023 г. в 12:03, Anton Vinogradov : > > > > > I looks like you're proposing not migration to 2.11 (because it is > > already > > > supported), but Java 8-9 support dropping. > > > > > > On Fri, Aug 25, 2023 at 11:54 AM Peter Ivanov > > wrote: > > > > > > > Hi, Igniters! > > > > > > > > > > > > I would like to propose the next, if you don't mind me saying, > > > > revolutionary step forward in our project: moving Ignite 2.x > > compilation > > > to > > > > JDK11 minimum version. > > > > I'd rather not make arguments, pros and cons other that currently > exist > > > in > > > > Java world - you know them better than me. Let's just say that it > seems > > > > that time has come - consider at least that JDK11 as the LTS version > is > > > > already about 4 and a half years on the go, and Ignite 3.x started > from > > > > JDK11 right away. > > > > > > > > This change may possibly require from us additional efforts on > > supporting > > > > the last version with JDK8 in terms of releasing additional patches > and > > > > hotfixes a bit longer than usual. However, this is up to the > community > > to > > > > decide. > > > > > > > > Currently, Apache Ignite 2.x (with Extensions as well) is already > > > prepared > > > > for being compiled with JDK11 and almost all tests are passing. If we > > > come > > > > to an agreement about this proposal and designate the next version > that > > > > will become the first to provide JDK11 compiled binaries - I am ready > > to > > > > start the process of updating the TeamCity building project > > accordingly. > > > > > > > > > > > > Please, share your thoughts. > > > > > > > > > > > > -- > Sincerely yours, Ivan Daschinskiy >
Re: [PROPOSAL] Move Ignite 2.x to JDK11 compilation
+1. It's time to do it at last. пт, 25 авг. 2023 г. в 12:06, Peter Ivanov : > Mostly, yes. > > In other words - proposal is about starting shipping Apache Ignite releases > with JDK11 compiled binaries thus dropping JDK8-10 runtime support. > > пт, 25 авг. 2023 г. в 12:03, Anton Vinogradov : > > > I looks like you're proposing not migration to 2.11 (because it is > already > > supported), but Java 8-9 support dropping. > > > > On Fri, Aug 25, 2023 at 11:54 AM Peter Ivanov > wrote: > > > > > Hi, Igniters! > > > > > > > > > I would like to propose the next, if you don't mind me saying, > > > revolutionary step forward in our project: moving Ignite 2.x > compilation > > to > > > JDK11 minimum version. > > > I'd rather not make arguments, pros and cons other that currently exist > > in > > > Java world - you know them better than me. Let's just say that it seems > > > that time has come - consider at least that JDK11 as the LTS version is > > > already about 4 and a half years on the go, and Ignite 3.x started from > > > JDK11 right away. > > > > > > This change may possibly require from us additional efforts on > supporting > > > the last version with JDK8 in terms of releasing additional patches and > > > hotfixes a bit longer than usual. However, this is up to the community > to > > > decide. > > > > > > Currently, Apache Ignite 2.x (with Extensions as well) is already > > prepared > > > for being compiled with JDK11 and almost all tests are passing. If we > > come > > > to an agreement about this proposal and designate the next version that > > > will become the first to provide JDK11 compiled binaries - I am ready > to > > > start the process of updating the TeamCity building project > accordingly. > > > > > > > > > Please, share your thoughts. > > > > > > -- Sincerely yours, Ivan Daschinskiy
Re: [PROPOSAL] Move Ignite 2.x to JDK11 compilation
Mostly, yes. In other words - proposal is about starting shipping Apache Ignite releases with JDK11 compiled binaries thus dropping JDK8-10 runtime support. пт, 25 авг. 2023 г. в 12:03, Anton Vinogradov : > I looks like you're proposing not migration to 2.11 (because it is already > supported), but Java 8-9 support dropping. > > On Fri, Aug 25, 2023 at 11:54 AM Peter Ivanov wrote: > > > Hi, Igniters! > > > > > > I would like to propose the next, if you don't mind me saying, > > revolutionary step forward in our project: moving Ignite 2.x compilation > to > > JDK11 minimum version. > > I'd rather not make arguments, pros and cons other that currently exist > in > > Java world - you know them better than me. Let's just say that it seems > > that time has come - consider at least that JDK11 as the LTS version is > > already about 4 and a half years on the go, and Ignite 3.x started from > > JDK11 right away. > > > > This change may possibly require from us additional efforts on supporting > > the last version with JDK8 in terms of releasing additional patches and > > hotfixes a bit longer than usual. However, this is up to the community to > > decide. > > > > Currently, Apache Ignite 2.x (with Extensions as well) is already > prepared > > for being compiled with JDK11 and almost all tests are passing. If we > come > > to an agreement about this proposal and designate the next version that > > will become the first to provide JDK11 compiled binaries - I am ready to > > start the process of updating the TeamCity building project accordingly. > > > > > > Please, share your thoughts. > > >
Re: [PROPOSAL] Move Ignite 2.x to JDK11 compilation
I looks like you're proposing not migration to 2.11 (because it is already supported), but Java 8-9 support dropping. On Fri, Aug 25, 2023 at 11:54 AM Peter Ivanov wrote: > Hi, Igniters! > > > I would like to propose the next, if you don't mind me saying, > revolutionary step forward in our project: moving Ignite 2.x compilation to > JDK11 minimum version. > I'd rather not make arguments, pros and cons other that currently exist in > Java world - you know them better than me. Let's just say that it seems > that time has come - consider at least that JDK11 as the LTS version is > already about 4 and a half years on the go, and Ignite 3.x started from > JDK11 right away. > > This change may possibly require from us additional efforts on supporting > the last version with JDK8 in terms of releasing additional patches and > hotfixes a bit longer than usual. However, this is up to the community to > decide. > > Currently, Apache Ignite 2.x (with Extensions as well) is already prepared > for being compiled with JDK11 and almost all tests are passing. If we come > to an agreement about this proposal and designate the next version that > will become the first to provide JDK11 compiled binaries - I am ready to > start the process of updating the TeamCity building project accordingly. > > > Please, share your thoughts. >
[PROPOSAL] Move Ignite 2.x to JDK11 compilation
Hi, Igniters! I would like to propose the next, if you don't mind me saying, revolutionary step forward in our project: moving Ignite 2.x compilation to JDK11 minimum version. I'd rather not make arguments, pros and cons other that currently exist in Java world - you know them better than me. Let's just say that it seems that time has come - consider at least that JDK11 as the LTS version is already about 4 and a half years on the go, and Ignite 3.x started from JDK11 right away. This change may possibly require from us additional efforts on supporting the last version with JDK8 in terms of releasing additional patches and hotfixes a bit longer than usual. However, this is up to the community to decide. Currently, Apache Ignite 2.x (with Extensions as well) is already prepared for being compiled with JDK11 and almost all tests are passing. If we come to an agreement about this proposal and designate the next version that will become the first to provide JDK11 compiled binaries - I am ready to start the process of updating the TeamCity building project accordingly. Please, share your thoughts.
Re: [PROPOSAL] Release Calcite-based SQL engine as an experimental feature
This is great news! Alex, thanks for making it to the end! -- Regards, Konstantin Orlov > On 24 Mar 2022, at 18:07, Alex Plehanov wrote: > > Hello Igniters, > > I've merged the pull request. The Calcite-based SQL engine is in the master > branch now. > If you desire to try it, you can find configuration instructions in > modules/calcite/README.txt file. > > вс, 6 мар. 2022 г. в 13:03, Alex Plehanov : > >> Hello Igniters, >> >> I've prepared the pull request [1] and have plans to merge it to the >> master branch in about two weeks, if there is no objection. >> >> [1]: https://github.com/apache/ignite/pull/9855 >> >> чт, 30 дек. 2021 г. в 13:43, Anton Vinogradov : >> it would be great to release a new SQL engine in 2.13 as an >>> experimental feature. >>> ++1 >>> >>> On Thu, Dec 30, 2021 at 12:55 PM Alex Plehanov >>> wrote: >>> Andrey, > Is this [1] a full scope of the tickets that MUST be resolved before >>> the engine could be merged? Yes, we must resolve at least these tickets before merging. If you see >>> any other release blockers fill free to attach them to this ticket. > I think we have to add instructions to the readme file on how to turn >>> a new SQL engine on. Sure, I think it should be the part of documentation ticket. > Also, I don't like the module name "ignite-calcite", because Calcite >>> is an independent project. Personally, I see no problems here (but it's discussable). We have a >>> lot of modules where the name is an independent project: "ignite-kafka", "ignite-spring", "ignite-kubernetes", "ignite-log4j", >>> "ignite-zookeeper", etc. > So, would you mind renaming the module to e.g. "ignite-sql-engine" or "ignite-sql"? Module "ignite-indexing" also contains SQL engine, so names like "ignite-sql-engine" or "ignite-sql" will be ambiguous. чт, 30 дек. 2021 г. в 13:54, Andrey Mashenkov < >>> andrey.mashen...@gmail.com > : > Alex, > it would be great to release a new SQL engine in 2.13 as an > experimental feature. > > Is this [1] a full scope of the tickets that MUST be resolved before >>> the > engine could be merged? > I think we have to add instructions to the readme file on how to turn >>> a new > SQL engine on. > > Also, I don't like the module name "ignite-calcite", because Calcite >>> is an > independent project. > and Ignite just uses it. > So, would you mind renaming the module to e.g. "ignite-sql-engine" or > "ignite-sql"? > > [1] https://issues.apache.org/jira/browse/IGNITE-15436 > > On Thu, Dec 30, 2021 at 11:10 AM Zhenya Stanilovsky > wrote: > >> >> Alex, great ! >> If someone wants to touch codebase somehow plz use this branch [1] >> Test passed can be found here [2] [3] >> >> [1] >>> https://github.com/apache/ignite/tree/sql-calcite/modules/calcite >> [2] >> > >>> https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/java/org/apache/ignite/internal/processors/query/calcite >> [3] >> > >>> https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/sql >> >>> > Hello, Igniters! > > As you may already know there is the new Ignite SQL engine based >>> on >> Apache > Calcite currently under development. > > Reasons to move from H2-based engine and motivation for creating >>> the > new > one in details described in IEP-37 [1]. > > You can find all related to the new engine source code changes in the > "sql-calcite" branch [2]. > > Calcite-based SQL engine is not production-ready yet and has a >>> lot of >> known > issues. In the future, the new engine should be fully >>> independent of > "ignite-indexing" and H2, but now it relies on schema management >>> and > indexes implemented in the "ignite-indexing" module and can't >>> work >> without > the old engine. Despite all of the above mentioned, in the >>> current >> state, > it has its own parsing, planning and execution flow and is >>> almost as > functional as the H2-based SQL engine. > > Some users are already interested in the Calcite-based engine and > asking > about the development status and release dates. Calcite-based SQL > engine > will be the only SQL engine in Ignite 3.0. Perhaps even in 2.x we can >> get > rid of the H2-based engine at some time in the future. There is >>> some >> syntax > difference between Calcite and H2 (Calcite is closer to SQL standards >> than > H2) and a totally new execution flow. After the release of this > feature, > users can try their queries and
Re: [PROPOSAL] Release Calcite-based SQL engine as an experimental feature
Great job! On Thu, Mar 24, 2022 at 6:27 PM Nikita Amelchev wrote: > Great news! > > I will cut the 2.13 release branch soon. > > чт, 24 мар. 2022 г. в 18:07, Alex Plehanov : > > > > > Hello Igniters, > > > > I've merged the pull request. The Calcite-based SQL engine is in the > master > > branch now. > > If you desire to try it, you can find configuration instructions in > > modules/calcite/README.txt file. > > > > вс, 6 мар. 2022 г. в 13:03, Alex Plehanov : > > > > > Hello Igniters, > > > > > > I've prepared the pull request [1] and have plans to merge it to the > > > master branch in about two weeks, if there is no objection. > > > > > > [1]: https://github.com/apache/ignite/pull/9855 > > > > > > чт, 30 дек. 2021 г. в 13:43, Anton Vinogradov : > > > > > >> > it would be great to release a new SQL engine in 2.13 as an > > >> experimental feature. > > >> ++1 > > >> > > >> On Thu, Dec 30, 2021 at 12:55 PM Alex Plehanov < > plehanov.a...@gmail.com> > > >> wrote: > > >> > > >> > Andrey, > > >> > > > >> > > Is this [1] a full scope of the tickets that MUST be resolved > before > > >> the > > >> > engine could be merged? > > >> > Yes, we must resolve at least these tickets before merging. If you > see > > >> any > > >> > other release blockers fill free to attach them to this ticket. > > >> > > > >> > > I think we have to add instructions to the readme file on how to > turn > > >> a > > >> > new SQL engine on. > > >> > Sure, I think it should be the part of documentation ticket. > > >> > > > >> > > Also, I don't like the module name "ignite-calcite", because > Calcite > > >> is > > >> > an independent project. > > >> > Personally, I see no problems here (but it's discussable). We have a > > >> lot of > > >> > modules where the name is an independent project: "ignite-kafka", > > >> > "ignite-spring", "ignite-kubernetes", "ignite-log4j", > > >> "ignite-zookeeper", > > >> > etc. > > >> > > > >> > > So, would you mind renaming the module to e.g. > "ignite-sql-engine" or > > >> > "ignite-sql"? > > >> > Module "ignite-indexing" also contains SQL engine, so names like > > >> > "ignite-sql-engine" or "ignite-sql" will be ambiguous. > > >> > > > >> > чт, 30 дек. 2021 г. в 13:54, Andrey Mashenkov < > > >> andrey.mashen...@gmail.com > > >> > >: > > >> > > > >> > > Alex, > > >> > > it would be great to release a new SQL engine in 2.13 as an > > >> > > experimental feature. > > >> > > > > >> > > Is this [1] a full scope of the tickets that MUST be resolved > before > > >> the > > >> > > engine could be merged? > > >> > > I think we have to add instructions to the readme file on how to > turn > > >> a > > >> > new > > >> > > SQL engine on. > > >> > > > > >> > > Also, I don't like the module name "ignite-calcite", because > Calcite > > >> is > > >> > an > > >> > > independent project. > > >> > > and Ignite just uses it. > > >> > > So, would you mind renaming the module to e.g. > "ignite-sql-engine" or > > >> > > "ignite-sql"? > > >> > > > > >> > > [1] https://issues.apache.org/jira/browse/IGNITE-15436 > > >> > > > > >> > > On Thu, Dec 30, 2021 at 11:10 AM Zhenya Stanilovsky > > >> > > wrote: > > >> > > > > >> > > > > > >> > > > Alex, great ! > > >> > > > If someone wants to touch codebase somehow plz use this branch > [1] > > >> > > > Test passed can be found here [2] [3] > > >> > > > > > >> > > > [1] > > >> https://github.com/apache/ignite/tree/sql-calcite/modules/calcite > > >> > > > [2] > > >> > > > > > >> > > > > >> > > > >> > https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/java/org/apache/ignite/internal/processors/query/calcite > > >> > > > [3] > > >> > > > > > >> > > > > >> > > > >> > https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/sql > > >> > > > > > >> > > > > > > >> > > > >> > > >> > > > >>>Hello, Igniters! > > >> > > > >>> > > >> > > > >>>As you may already know there is the new Ignite SQL engine > based > > >> on > > >> > > > Apache > > >> > > > >>>Calcite currently under development. > > >> > > > >>> > > >> > > > >>>Reasons to move from H2-based engine and motivation for > creating > > >> the > > >> > > new > > >> > > > >>>one in details described in IEP-37 [1]. > > >> > > > >>> > > >> > > > >>>You can find all related to the new engine source code > changes in > > >> > the > > >> > > > >>>"sql-calcite" branch [2]. > > >> > > > >>> > > >> > > > >>>Calcite-based SQL engine is not production-ready yet and has > a > > >> lot > > >> > of > > >> > > > known > > >> > > > >>>issues. In the future, the new engine should be fully > > >> independent of > > >> > > > >>>"ignite-indexing" and H2, but now it relies on schema > management > > >> and > > >> > > > >>>indexes implemented in the "ignite-indexing" module and can't > > >> work > > >> > > > without > > >> > > > >>>the old engine. Despite all of the above mentioned, in the > > >> current > > >> > > > state, > > >> > > > >>>it has its own parsing, planning and execution flow and is > > >> almost as > > >> > >
Re: [PROPOSAL] Release Calcite-based SQL engine as an experimental feature
Great news! I will cut the 2.13 release branch soon. чт, 24 мар. 2022 г. в 18:07, Alex Plehanov : > > Hello Igniters, > > I've merged the pull request. The Calcite-based SQL engine is in the master > branch now. > If you desire to try it, you can find configuration instructions in > modules/calcite/README.txt file. > > вс, 6 мар. 2022 г. в 13:03, Alex Plehanov : > > > Hello Igniters, > > > > I've prepared the pull request [1] and have plans to merge it to the > > master branch in about two weeks, if there is no objection. > > > > [1]: https://github.com/apache/ignite/pull/9855 > > > > чт, 30 дек. 2021 г. в 13:43, Anton Vinogradov : > > > >> > it would be great to release a new SQL engine in 2.13 as an > >> experimental feature. > >> ++1 > >> > >> On Thu, Dec 30, 2021 at 12:55 PM Alex Plehanov > >> wrote: > >> > >> > Andrey, > >> > > >> > > Is this [1] a full scope of the tickets that MUST be resolved before > >> the > >> > engine could be merged? > >> > Yes, we must resolve at least these tickets before merging. If you see > >> any > >> > other release blockers fill free to attach them to this ticket. > >> > > >> > > I think we have to add instructions to the readme file on how to turn > >> a > >> > new SQL engine on. > >> > Sure, I think it should be the part of documentation ticket. > >> > > >> > > Also, I don't like the module name "ignite-calcite", because Calcite > >> is > >> > an independent project. > >> > Personally, I see no problems here (but it's discussable). We have a > >> lot of > >> > modules where the name is an independent project: "ignite-kafka", > >> > "ignite-spring", "ignite-kubernetes", "ignite-log4j", > >> "ignite-zookeeper", > >> > etc. > >> > > >> > > So, would you mind renaming the module to e.g. "ignite-sql-engine" or > >> > "ignite-sql"? > >> > Module "ignite-indexing" also contains SQL engine, so names like > >> > "ignite-sql-engine" or "ignite-sql" will be ambiguous. > >> > > >> > чт, 30 дек. 2021 г. в 13:54, Andrey Mashenkov < > >> andrey.mashen...@gmail.com > >> > >: > >> > > >> > > Alex, > >> > > it would be great to release a new SQL engine in 2.13 as an > >> > > experimental feature. > >> > > > >> > > Is this [1] a full scope of the tickets that MUST be resolved before > >> the > >> > > engine could be merged? > >> > > I think we have to add instructions to the readme file on how to turn > >> a > >> > new > >> > > SQL engine on. > >> > > > >> > > Also, I don't like the module name "ignite-calcite", because Calcite > >> is > >> > an > >> > > independent project. > >> > > and Ignite just uses it. > >> > > So, would you mind renaming the module to e.g. "ignite-sql-engine" or > >> > > "ignite-sql"? > >> > > > >> > > [1] https://issues.apache.org/jira/browse/IGNITE-15436 > >> > > > >> > > On Thu, Dec 30, 2021 at 11:10 AM Zhenya Stanilovsky > >> > > wrote: > >> > > > >> > > > > >> > > > Alex, great ! > >> > > > If someone wants to touch codebase somehow plz use this branch [1] > >> > > > Test passed can be found here [2] [3] > >> > > > > >> > > > [1] > >> https://github.com/apache/ignite/tree/sql-calcite/modules/calcite > >> > > > [2] > >> > > > > >> > > > >> > > >> https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/java/org/apache/ignite/internal/processors/query/calcite > >> > > > [3] > >> > > > > >> > > > >> > > >> https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/sql > >> > > > > >> > > > > > >> > > > >> > >> > > > >>>Hello, Igniters! > >> > > > >>> > >> > > > >>>As you may already know there is the new Ignite SQL engine based > >> on > >> > > > Apache > >> > > > >>>Calcite currently under development. > >> > > > >>> > >> > > > >>>Reasons to move from H2-based engine and motivation for creating > >> the > >> > > new > >> > > > >>>one in details described in IEP-37 [1]. > >> > > > >>> > >> > > > >>>You can find all related to the new engine source code changes in > >> > the > >> > > > >>>"sql-calcite" branch [2]. > >> > > > >>> > >> > > > >>>Calcite-based SQL engine is not production-ready yet and has a > >> lot > >> > of > >> > > > known > >> > > > >>>issues. In the future, the new engine should be fully > >> independent of > >> > > > >>>"ignite-indexing" and H2, but now it relies on schema management > >> and > >> > > > >>>indexes implemented in the "ignite-indexing" module and can't > >> work > >> > > > without > >> > > > >>>the old engine. Despite all of the above mentioned, in the > >> current > >> > > > state, > >> > > > >>>it has its own parsing, planning and execution flow and is > >> almost as > >> > > > >>>functional as the H2-based SQL engine. > >> > > > >>> > >> > > > >>>Some users are already interested in the Calcite-based engine and > >> > > asking > >> > > > >>>about the development status and release dates. Calcite-based SQL > >> > > engine > >> > > > >>>will be the only SQL engine in Ignite 3.0. Perhaps even in 2.x we > >> > can > >> > > > get > >> > > > >>>rid of the H2-based engine at some time in
Re: [PROPOSAL] Release Calcite-based SQL engine as an experimental feature
Hello Igniters, I've merged the pull request. The Calcite-based SQL engine is in the master branch now. If you desire to try it, you can find configuration instructions in modules/calcite/README.txt file. вс, 6 мар. 2022 г. в 13:03, Alex Plehanov : > Hello Igniters, > > I've prepared the pull request [1] and have plans to merge it to the > master branch in about two weeks, if there is no objection. > > [1]: https://github.com/apache/ignite/pull/9855 > > чт, 30 дек. 2021 г. в 13:43, Anton Vinogradov : > >> > it would be great to release a new SQL engine in 2.13 as an >> experimental feature. >> ++1 >> >> On Thu, Dec 30, 2021 at 12:55 PM Alex Plehanov >> wrote: >> >> > Andrey, >> > >> > > Is this [1] a full scope of the tickets that MUST be resolved before >> the >> > engine could be merged? >> > Yes, we must resolve at least these tickets before merging. If you see >> any >> > other release blockers fill free to attach them to this ticket. >> > >> > > I think we have to add instructions to the readme file on how to turn >> a >> > new SQL engine on. >> > Sure, I think it should be the part of documentation ticket. >> > >> > > Also, I don't like the module name "ignite-calcite", because Calcite >> is >> > an independent project. >> > Personally, I see no problems here (but it's discussable). We have a >> lot of >> > modules where the name is an independent project: "ignite-kafka", >> > "ignite-spring", "ignite-kubernetes", "ignite-log4j", >> "ignite-zookeeper", >> > etc. >> > >> > > So, would you mind renaming the module to e.g. "ignite-sql-engine" or >> > "ignite-sql"? >> > Module "ignite-indexing" also contains SQL engine, so names like >> > "ignite-sql-engine" or "ignite-sql" will be ambiguous. >> > >> > чт, 30 дек. 2021 г. в 13:54, Andrey Mashenkov < >> andrey.mashen...@gmail.com >> > >: >> > >> > > Alex, >> > > it would be great to release a new SQL engine in 2.13 as an >> > > experimental feature. >> > > >> > > Is this [1] a full scope of the tickets that MUST be resolved before >> the >> > > engine could be merged? >> > > I think we have to add instructions to the readme file on how to turn >> a >> > new >> > > SQL engine on. >> > > >> > > Also, I don't like the module name "ignite-calcite", because Calcite >> is >> > an >> > > independent project. >> > > and Ignite just uses it. >> > > So, would you mind renaming the module to e.g. "ignite-sql-engine" or >> > > "ignite-sql"? >> > > >> > > [1] https://issues.apache.org/jira/browse/IGNITE-15436 >> > > >> > > On Thu, Dec 30, 2021 at 11:10 AM Zhenya Stanilovsky >> > > wrote: >> > > >> > > > >> > > > Alex, great ! >> > > > If someone wants to touch codebase somehow plz use this branch [1] >> > > > Test passed can be found here [2] [3] >> > > > >> > > > [1] >> https://github.com/apache/ignite/tree/sql-calcite/modules/calcite >> > > > [2] >> > > > >> > > >> > >> https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/java/org/apache/ignite/internal/processors/query/calcite >> > > > [3] >> > > > >> > > >> > >> https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/sql >> > > > >> > > > > >> > > > >> >> > > > >>>Hello, Igniters! >> > > > >>> >> > > > >>>As you may already know there is the new Ignite SQL engine based >> on >> > > > Apache >> > > > >>>Calcite currently under development. >> > > > >>> >> > > > >>>Reasons to move from H2-based engine and motivation for creating >> the >> > > new >> > > > >>>one in details described in IEP-37 [1]. >> > > > >>> >> > > > >>>You can find all related to the new engine source code changes in >> > the >> > > > >>>"sql-calcite" branch [2]. >> > > > >>> >> > > > >>>Calcite-based SQL engine is not production-ready yet and has a >> lot >> > of >> > > > known >> > > > >>>issues. In the future, the new engine should be fully >> independent of >> > > > >>>"ignite-indexing" and H2, but now it relies on schema management >> and >> > > > >>>indexes implemented in the "ignite-indexing" module and can't >> work >> > > > without >> > > > >>>the old engine. Despite all of the above mentioned, in the >> current >> > > > state, >> > > > >>>it has its own parsing, planning and execution flow and is >> almost as >> > > > >>>functional as the H2-based SQL engine. >> > > > >>> >> > > > >>>Some users are already interested in the Calcite-based engine and >> > > asking >> > > > >>>about the development status and release dates. Calcite-based SQL >> > > engine >> > > > >>>will be the only SQL engine in Ignite 3.0. Perhaps even in 2.x we >> > can >> > > > get >> > > > >>>rid of the H2-based engine at some time in the future. There is >> some >> > > > syntax >> > > > >>>difference between Calcite and H2 (Calcite is closer to SQL >> > standards >> > > > than >> > > > >>>H2) and a totally new execution flow. After the release of this >> > > feature, >> > > > >>>users can try their queries and determine if any adaptation for >> them >> > > is >> > > > >>>required. With the new planning and execution
Re: [PROPOSAL] Release Calcite-based SQL engine as an experimental feature
Hello Igniters, I've prepared the pull request [1] and have plans to merge it to the master branch in about two weeks, if there is no objection. [1]: https://github.com/apache/ignite/pull/9855 чт, 30 дек. 2021 г. в 13:43, Anton Vinogradov : > > it would be great to release a new SQL engine in 2.13 as an > experimental feature. > ++1 > > On Thu, Dec 30, 2021 at 12:55 PM Alex Plehanov > wrote: > > > Andrey, > > > > > Is this [1] a full scope of the tickets that MUST be resolved before > the > > engine could be merged? > > Yes, we must resolve at least these tickets before merging. If you see > any > > other release blockers fill free to attach them to this ticket. > > > > > I think we have to add instructions to the readme file on how to turn a > > new SQL engine on. > > Sure, I think it should be the part of documentation ticket. > > > > > Also, I don't like the module name "ignite-calcite", because Calcite is > > an independent project. > > Personally, I see no problems here (but it's discussable). We have a lot > of > > modules where the name is an independent project: "ignite-kafka", > > "ignite-spring", "ignite-kubernetes", "ignite-log4j", "ignite-zookeeper", > > etc. > > > > > So, would you mind renaming the module to e.g. "ignite-sql-engine" or > > "ignite-sql"? > > Module "ignite-indexing" also contains SQL engine, so names like > > "ignite-sql-engine" or "ignite-sql" will be ambiguous. > > > > чт, 30 дек. 2021 г. в 13:54, Andrey Mashenkov < > andrey.mashen...@gmail.com > > >: > > > > > Alex, > > > it would be great to release a new SQL engine in 2.13 as an > > > experimental feature. > > > > > > Is this [1] a full scope of the tickets that MUST be resolved before > the > > > engine could be merged? > > > I think we have to add instructions to the readme file on how to turn a > > new > > > SQL engine on. > > > > > > Also, I don't like the module name "ignite-calcite", because Calcite is > > an > > > independent project. > > > and Ignite just uses it. > > > So, would you mind renaming the module to e.g. "ignite-sql-engine" or > > > "ignite-sql"? > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15436 > > > > > > On Thu, Dec 30, 2021 at 11:10 AM Zhenya Stanilovsky > > > wrote: > > > > > > > > > > > Alex, great ! > > > > If someone wants to touch codebase somehow plz use this branch [1] > > > > Test passed can be found here [2] [3] > > > > > > > > [1] > https://github.com/apache/ignite/tree/sql-calcite/modules/calcite > > > > [2] > > > > > > > > > > https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/java/org/apache/ignite/internal/processors/query/calcite > > > > [3] > > > > > > > > > > https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/sql > > > > > > > > > > > > > >> > > > > >>>Hello, Igniters! > > > > >>> > > > > >>>As you may already know there is the new Ignite SQL engine based > on > > > > Apache > > > > >>>Calcite currently under development. > > > > >>> > > > > >>>Reasons to move from H2-based engine and motivation for creating > the > > > new > > > > >>>one in details described in IEP-37 [1]. > > > > >>> > > > > >>>You can find all related to the new engine source code changes in > > the > > > > >>>"sql-calcite" branch [2]. > > > > >>> > > > > >>>Calcite-based SQL engine is not production-ready yet and has a lot > > of > > > > known > > > > >>>issues. In the future, the new engine should be fully independent > of > > > > >>>"ignite-indexing" and H2, but now it relies on schema management > and > > > > >>>indexes implemented in the "ignite-indexing" module and can't work > > > > without > > > > >>>the old engine. Despite all of the above mentioned, in the current > > > > state, > > > > >>>it has its own parsing, planning and execution flow and is almost > as > > > > >>>functional as the H2-based SQL engine. > > > > >>> > > > > >>>Some users are already interested in the Calcite-based engine and > > > asking > > > > >>>about the development status and release dates. Calcite-based SQL > > > engine > > > > >>>will be the only SQL engine in Ignite 3.0. Perhaps even in 2.x we > > can > > > > get > > > > >>>rid of the H2-based engine at some time in the future. There is > some > > > > syntax > > > > >>>difference between Calcite and H2 (Calcite is closer to SQL > > standards > > > > than > > > > >>>H2) and a totally new execution flow. After the release of this > > > feature, > > > > >>>users can try their queries and determine if any adaptation for > them > > > is > > > > >>>required. With the new planning and execution flow, perhaps, some > > > > queries > > > > >>>will be executed more effectively, users can redirect such queries > > to > > > > the > > > > >>>new engine. > > > > >>> > > > > >>>I think we can provide an opportunity to users to try the new > engine > > > and > > > > >>>release it as an experimental feature with the next Apache Ignite > > > > version > > > > >>>(2.13). > > > > >>> > > > > >>>What do you think? > > > >
Re: [PROPOSAL] Release Calcite-based SQL engine as an experimental feature
> it would be great to release a new SQL engine in 2.13 as an experimental feature. ++1 On Thu, Dec 30, 2021 at 12:55 PM Alex Plehanov wrote: > Andrey, > > > Is this [1] a full scope of the tickets that MUST be resolved before the > engine could be merged? > Yes, we must resolve at least these tickets before merging. If you see any > other release blockers fill free to attach them to this ticket. > > > I think we have to add instructions to the readme file on how to turn a > new SQL engine on. > Sure, I think it should be the part of documentation ticket. > > > Also, I don't like the module name "ignite-calcite", because Calcite is > an independent project. > Personally, I see no problems here (but it's discussable). We have a lot of > modules where the name is an independent project: "ignite-kafka", > "ignite-spring", "ignite-kubernetes", "ignite-log4j", "ignite-zookeeper", > etc. > > > So, would you mind renaming the module to e.g. "ignite-sql-engine" or > "ignite-sql"? > Module "ignite-indexing" also contains SQL engine, so names like > "ignite-sql-engine" or "ignite-sql" will be ambiguous. > > чт, 30 дек. 2021 г. в 13:54, Andrey Mashenkov >: > > > Alex, > > it would be great to release a new SQL engine in 2.13 as an > > experimental feature. > > > > Is this [1] a full scope of the tickets that MUST be resolved before the > > engine could be merged? > > I think we have to add instructions to the readme file on how to turn a > new > > SQL engine on. > > > > Also, I don't like the module name "ignite-calcite", because Calcite is > an > > independent project. > > and Ignite just uses it. > > So, would you mind renaming the module to e.g. "ignite-sql-engine" or > > "ignite-sql"? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15436 > > > > On Thu, Dec 30, 2021 at 11:10 AM Zhenya Stanilovsky > > wrote: > > > > > > > > Alex, great ! > > > If someone wants to touch codebase somehow plz use this branch [1] > > > Test passed can be found here [2] [3] > > > > > > [1] https://github.com/apache/ignite/tree/sql-calcite/modules/calcite > > > [2] > > > > > > https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/java/org/apache/ignite/internal/processors/query/calcite > > > [3] > > > > > > https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/sql > > > > > > > > > > >> > > > >>>Hello, Igniters! > > > >>> > > > >>>As you may already know there is the new Ignite SQL engine based on > > > Apache > > > >>>Calcite currently under development. > > > >>> > > > >>>Reasons to move from H2-based engine and motivation for creating the > > new > > > >>>one in details described in IEP-37 [1]. > > > >>> > > > >>>You can find all related to the new engine source code changes in > the > > > >>>"sql-calcite" branch [2]. > > > >>> > > > >>>Calcite-based SQL engine is not production-ready yet and has a lot > of > > > known > > > >>>issues. In the future, the new engine should be fully independent of > > > >>>"ignite-indexing" and H2, but now it relies on schema management and > > > >>>indexes implemented in the "ignite-indexing" module and can't work > > > without > > > >>>the old engine. Despite all of the above mentioned, in the current > > > state, > > > >>>it has its own parsing, planning and execution flow and is almost as > > > >>>functional as the H2-based SQL engine. > > > >>> > > > >>>Some users are already interested in the Calcite-based engine and > > asking > > > >>>about the development status and release dates. Calcite-based SQL > > engine > > > >>>will be the only SQL engine in Ignite 3.0. Perhaps even in 2.x we > can > > > get > > > >>>rid of the H2-based engine at some time in the future. There is some > > > syntax > > > >>>difference between Calcite and H2 (Calcite is closer to SQL > standards > > > than > > > >>>H2) and a totally new execution flow. After the release of this > > feature, > > > >>>users can try their queries and determine if any adaptation for them > > is > > > >>>required. With the new planning and execution flow, perhaps, some > > > queries > > > >>>will be executed more effectively, users can redirect such queries > to > > > the > > > >>>new engine. > > > >>> > > > >>>I think we can provide an opportunity to users to try the new engine > > and > > > >>>release it as an experimental feature with the next Apache Ignite > > > version > > > >>>(2.13). > > > >>> > > > >>>What do you think? > > > >> > > > >> > > > >> > > > >> > > > > > > > > -- > > Best regards, > > Andrey V. Mashenkov > > >
Re: [PROPOSAL] Release Calcite-based SQL engine as an experimental feature
Andrey, > Is this [1] a full scope of the tickets that MUST be resolved before the engine could be merged? Yes, we must resolve at least these tickets before merging. If you see any other release blockers fill free to attach them to this ticket. > I think we have to add instructions to the readme file on how to turn a new SQL engine on. Sure, I think it should be the part of documentation ticket. > Also, I don't like the module name "ignite-calcite", because Calcite is an independent project. Personally, I see no problems here (but it's discussable). We have a lot of modules where the name is an independent project: "ignite-kafka", "ignite-spring", "ignite-kubernetes", "ignite-log4j", "ignite-zookeeper", etc. > So, would you mind renaming the module to e.g. "ignite-sql-engine" or "ignite-sql"? Module "ignite-indexing" also contains SQL engine, so names like "ignite-sql-engine" or "ignite-sql" will be ambiguous. чт, 30 дек. 2021 г. в 13:54, Andrey Mashenkov : > Alex, > it would be great to release a new SQL engine in 2.13 as an > experimental feature. > > Is this [1] a full scope of the tickets that MUST be resolved before the > engine could be merged? > I think we have to add instructions to the readme file on how to turn a new > SQL engine on. > > Also, I don't like the module name "ignite-calcite", because Calcite is an > independent project. > and Ignite just uses it. > So, would you mind renaming the module to e.g. "ignite-sql-engine" or > "ignite-sql"? > > [1] https://issues.apache.org/jira/browse/IGNITE-15436 > > On Thu, Dec 30, 2021 at 11:10 AM Zhenya Stanilovsky > wrote: > > > > > Alex, great ! > > If someone wants to touch codebase somehow plz use this branch [1] > > Test passed can be found here [2] [3] > > > > [1] https://github.com/apache/ignite/tree/sql-calcite/modules/calcite > > [2] > > > https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/java/org/apache/ignite/internal/processors/query/calcite > > [3] > > > https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/sql > > > > > > > >> > > >>>Hello, Igniters! > > >>> > > >>>As you may already know there is the new Ignite SQL engine based on > > Apache > > >>>Calcite currently under development. > > >>> > > >>>Reasons to move from H2-based engine and motivation for creating the > new > > >>>one in details described in IEP-37 [1]. > > >>> > > >>>You can find all related to the new engine source code changes in the > > >>>"sql-calcite" branch [2]. > > >>> > > >>>Calcite-based SQL engine is not production-ready yet and has a lot of > > known > > >>>issues. In the future, the new engine should be fully independent of > > >>>"ignite-indexing" and H2, but now it relies on schema management and > > >>>indexes implemented in the "ignite-indexing" module and can't work > > without > > >>>the old engine. Despite all of the above mentioned, in the current > > state, > > >>>it has its own parsing, planning and execution flow and is almost as > > >>>functional as the H2-based SQL engine. > > >>> > > >>>Some users are already interested in the Calcite-based engine and > asking > > >>>about the development status and release dates. Calcite-based SQL > engine > > >>>will be the only SQL engine in Ignite 3.0. Perhaps even in 2.x we can > > get > > >>>rid of the H2-based engine at some time in the future. There is some > > syntax > > >>>difference between Calcite and H2 (Calcite is closer to SQL standards > > than > > >>>H2) and a totally new execution flow. After the release of this > feature, > > >>>users can try their queries and determine if any adaptation for them > is > > >>>required. With the new planning and execution flow, perhaps, some > > queries > > >>>will be executed more effectively, users can redirect such queries to > > the > > >>>new engine. > > >>> > > >>>I think we can provide an opportunity to users to try the new engine > and > > >>>release it as an experimental feature with the next Apache Ignite > > version > > >>>(2.13). > > >>> > > >>>What do you think? > > >> > > >> > > >> > > >> > > > > -- > Best regards, > Andrey V. Mashenkov >
Re: [PROPOSAL] Release Calcite-based SQL engine as an experimental feature
Alex, it would be great to release a new SQL engine in 2.13 as an experimental feature. Is this [1] a full scope of the tickets that MUST be resolved before the engine could be merged? I think we have to add instructions to the readme file on how to turn a new SQL engine on. Also, I don't like the module name "ignite-calcite", because Calcite is an independent project. and Ignite just uses it. So, would you mind renaming the module to e.g. "ignite-sql-engine" or "ignite-sql"? [1] https://issues.apache.org/jira/browse/IGNITE-15436 On Thu, Dec 30, 2021 at 11:10 AM Zhenya Stanilovsky wrote: > > Alex, great ! > If someone wants to touch codebase somehow plz use this branch [1] > Test passed can be found here [2] [3] > > [1] https://github.com/apache/ignite/tree/sql-calcite/modules/calcite > [2] > https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/java/org/apache/ignite/internal/processors/query/calcite > [3] > https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/sql > > > > >> > >>>Hello, Igniters! > >>> > >>>As you may already know there is the new Ignite SQL engine based on > Apache > >>>Calcite currently under development. > >>> > >>>Reasons to move from H2-based engine and motivation for creating the new > >>>one in details described in IEP-37 [1]. > >>> > >>>You can find all related to the new engine source code changes in the > >>>"sql-calcite" branch [2]. > >>> > >>>Calcite-based SQL engine is not production-ready yet and has a lot of > known > >>>issues. In the future, the new engine should be fully independent of > >>>"ignite-indexing" and H2, but now it relies on schema management and > >>>indexes implemented in the "ignite-indexing" module and can't work > without > >>>the old engine. Despite all of the above mentioned, in the current > state, > >>>it has its own parsing, planning and execution flow and is almost as > >>>functional as the H2-based SQL engine. > >>> > >>>Some users are already interested in the Calcite-based engine and asking > >>>about the development status and release dates. Calcite-based SQL engine > >>>will be the only SQL engine in Ignite 3.0. Perhaps even in 2.x we can > get > >>>rid of the H2-based engine at some time in the future. There is some > syntax > >>>difference between Calcite and H2 (Calcite is closer to SQL standards > than > >>>H2) and a totally new execution flow. After the release of this feature, > >>>users can try their queries and determine if any adaptation for them is > >>>required. With the new planning and execution flow, perhaps, some > queries > >>>will be executed more effectively, users can redirect such queries to > the > >>>new engine. > >>> > >>>I think we can provide an opportunity to users to try the new engine and > >>>release it as an experimental feature with the next Apache Ignite > version > >>>(2.13). > >>> > >>>What do you think? > >> > >> > >> > >> -- Best regards, Andrey V. Mashenkov
Re: [PROPOSAL] Release Calcite-based SQL engine as an experimental feature
Alex, great ! If someone wants to touch codebase somehow plz use this branch [1] Test passed can be found here [2] [3] [1] https://github.com/apache/ignite/tree/sql-calcite/modules/calcite [2] https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/java/org/apache/ignite/internal/processors/query/calcite [3] https://github.com/apache/ignite/tree/sql-calcite/modules/calcite/src/test/sql > >> >>>Hello, Igniters! >>> >>>As you may already know there is the new Ignite SQL engine based on Apache >>>Calcite currently under development. >>> >>>Reasons to move from H2-based engine and motivation for creating the new >>>one in details described in IEP-37 [1]. >>> >>>You can find all related to the new engine source code changes in the >>>"sql-calcite" branch [2]. >>> >>>Calcite-based SQL engine is not production-ready yet and has a lot of known >>>issues. In the future, the new engine should be fully independent of >>>"ignite-indexing" and H2, but now it relies on schema management and >>>indexes implemented in the "ignite-indexing" module and can't work without >>>the old engine. Despite all of the above mentioned, in the current state, >>>it has its own parsing, planning and execution flow and is almost as >>>functional as the H2-based SQL engine. >>> >>>Some users are already interested in the Calcite-based engine and asking >>>about the development status and release dates. Calcite-based SQL engine >>>will be the only SQL engine in Ignite 3.0. Perhaps even in 2.x we can get >>>rid of the H2-based engine at some time in the future. There is some syntax >>>difference between Calcite and H2 (Calcite is closer to SQL standards than >>>H2) and a totally new execution flow. After the release of this feature, >>>users can try their queries and determine if any adaptation for them is >>>required. With the new planning and execution flow, perhaps, some queries >>>will be executed more effectively, users can redirect such queries to the >>>new engine. >>> >>>I think we can provide an opportunity to users to try the new engine and >>>release it as an experimental feature with the next Apache Ignite version >>>(2.13). >>> >>>What do you think? >> >> >> >>
Re: [PROPOSAL] Release Calcite-based SQL engine as an experimental feature
I forgot to attach links: [1]: https://cwiki.apache.org/confluence/display/IGNITE/IEP-37%3A+New+query+execution+engine [2]: https://github.com/apache/ignite/tree/sql-calcite ср, 29 дек. 2021 г. в 21:00, Alex Plehanov : > Hello, Igniters! > > As you may already know there is the new Ignite SQL engine based on Apache > Calcite currently under development. > > Reasons to move from H2-based engine and motivation for creating the new > one in details described in IEP-37 [1]. > > You can find all related to the new engine source code changes in the > "sql-calcite" branch [2]. > > Calcite-based SQL engine is not production-ready yet and has a lot of > known issues. In the future, the new engine should be fully independent of > "ignite-indexing" and H2, but now it relies on schema management and > indexes implemented in the "ignite-indexing" module and can't work without > the old engine. Despite all of the above mentioned, in the current state, > it has its own parsing, planning and execution flow and is almost as > functional as the H2-based SQL engine. > > Some users are already interested in the Calcite-based engine and asking > about the development status and release dates. Calcite-based SQL engine > will be the only SQL engine in Ignite 3.0. Perhaps even in 2.x we can get > rid of the H2-based engine at some time in the future. There is some syntax > difference between Calcite and H2 (Calcite is closer to SQL standards than > H2) and a totally new execution flow. After the release of this feature, > users can try their queries and determine if any adaptation for them is > required. With the new planning and execution flow, perhaps, some queries > will be executed more effectively, users can redirect such queries to the > new engine. > > I think we can provide an opportunity to users to try the new engine and > release it as an experimental feature with the next Apache Ignite version > (2.13). > > What do you think? >
[PROPOSAL] Release Calcite-based SQL engine as an experimental feature
Hello, Igniters! As you may already know there is the new Ignite SQL engine based on Apache Calcite currently under development. Reasons to move from H2-based engine and motivation for creating the new one in details described in IEP-37 [1]. You can find all related to the new engine source code changes in the "sql-calcite" branch [2]. Calcite-based SQL engine is not production-ready yet and has a lot of known issues. In the future, the new engine should be fully independent of "ignite-indexing" and H2, but now it relies on schema management and indexes implemented in the "ignite-indexing" module and can't work without the old engine. Despite all of the above mentioned, in the current state, it has its own parsing, planning and execution flow and is almost as functional as the H2-based SQL engine. Some users are already interested in the Calcite-based engine and asking about the development status and release dates. Calcite-based SQL engine will be the only SQL engine in Ignite 3.0. Perhaps even in 2.x we can get rid of the H2-based engine at some time in the future. There is some syntax difference between Calcite and H2 (Calcite is closer to SQL standards than H2) and a totally new execution flow. After the release of this feature, users can try their queries and determine if any adaptation for them is required. With the new planning and execution flow, perhaps, some queries will be executed more effectively, users can redirect such queries to the new engine. I think we can provide an opportunity to users to try the new engine and release it as an experimental feature with the next Apache Ignite version (2.13). What do you think?
Re: API Proposal: Declare IgniteClient::close that throws no exceptions (IGNITE-15688)
Patch, PR and visa are in the ticket. Igor, please review and merge when you're ready. Thanks, Stan > On 6 Oct 2021, at 12:54, Igor Sapego wrote: > > Sounds good, no objections from my side. > > Best Regards, > Igor > > > On Wed, Oct 6, 2021 at 11:46 AM Stanislav Lukyanov > wrote: > >> Hi Igniters, >> >> I found the following usability issue with java thin client API. >> >> Whenever you do `try (IgniteClient client = Ignition.startClient(cfg))`, >> you're forced to declare `catch (Exception e)`. >> >> This is because IgniteClient interface currently doesn't override close() >> from AutoClosable. Because of that, it inherits `close() throws Exception`. >> >> In fact, this shouldn't be required. `TcpIgniteClient implements >> IgniteClient` currently throws Exception but it doesn't need to - its code >> doesn't throw any checked exceptions. >> >> Proposal: >>• Add `@Overrides public void close()` with no `throws` to >> IgniteClient. >>• Remove `throws Exception` from `TcpIgniteClient::close` >> Note: this change is fully backwards-compatible. It is legal to narrow the >> scope of `throws` in a new version of a method. >> >> I plan to do this in https://issues.apache.org/jira/browse/IGNITE-15688. >> >> Any objections? >> >> Thanks, >> Stan
Re: API Proposal: Declare IgniteClient::close that throws no exceptions (IGNITE-15688)
Sounds good, no objections from my side. Best Regards, Igor On Wed, Oct 6, 2021 at 11:46 AM Stanislav Lukyanov wrote: > Hi Igniters, > > I found the following usability issue with java thin client API. > > Whenever you do `try (IgniteClient client = Ignition.startClient(cfg))`, > you're forced to declare `catch (Exception e)`. > > This is because IgniteClient interface currently doesn't override close() > from AutoClosable. Because of that, it inherits `close() throws Exception`. > > In fact, this shouldn't be required. `TcpIgniteClient implements > IgniteClient` currently throws Exception but it doesn't need to - its code > doesn't throw any checked exceptions. > > Proposal: > • Add `@Overrides public void close()` with no `throws` to > IgniteClient. > • Remove `throws Exception` from `TcpIgniteClient::close` > Note: this change is fully backwards-compatible. It is legal to narrow the > scope of `throws` in a new version of a method. > > I plan to do this in https://issues.apache.org/jira/browse/IGNITE-15688. > > Any objections? > > Thanks, > Stan
API Proposal: Declare IgniteClient::close that throws no exceptions (IGNITE-15688)
Hi Igniters, I found the following usability issue with java thin client API. Whenever you do `try (IgniteClient client = Ignition.startClient(cfg))`, you're forced to declare `catch (Exception e)`. This is because IgniteClient interface currently doesn't override close() from AutoClosable. Because of that, it inherits `close() throws Exception`. In fact, this shouldn't be required. `TcpIgniteClient implements IgniteClient` currently throws Exception but it doesn't need to - its code doesn't throw any checked exceptions. Proposal: • Add `@Overrides public void close()` with no `throws` to IgniteClient. • Remove `throws Exception` from `TcpIgniteClient::close` Note: this change is fully backwards-compatible. It is legal to narrow the scope of `throws` in a new version of a method. I plan to do this in https://issues.apache.org/jira/browse/IGNITE-15688. Any objections? Thanks, Stan
Re: Release of pyignite 0.5.2 proposal
Well, I will start new voting thread soon Branch is ready, tag of rc0 is created [1], artifacts are ready [2] [1] -- https://github.com/apache/ignite-python-thin-client/releases/tag/0.5.2.rc0 [2] -- https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.5.2-rc0/ пт, 10 сент. 2021 г. в 14:55, Igor Sapego : > +1 > > Best Regards, > Igor > > > On Thu, Sep 9, 2021 at 8:33 PM Maxim Muzafarov wrote: > > > +1 > > > > On Thu, 9 Sept 2021 at 14:08, Nikolay Izhikov > wrote: > > > > > > +1 to release ASAP. > > > > > > > 9 сент. 2021 г., в 13:43, Ivan Daschinsky > > написал(а): > > > > > > > > TC build of release branch -- > > > > > > > https://tc.sbt-ignite-dev.ru/buildConfiguration/IgniteThinClients_Tests_ThinClientPython/6130289 > > > > > > > > чт, 9 сент. 2021 г. в 13:40, Ivan Daschinsky : > > > > > > > >> Hi, folks. > > > >> > > > >> Unfortunately, a quite severe bug found in pyignite since 0.4.0 was > > found > > > >> [1]. Fortunately, it is already fixed. Also there are also a few > bugs > > > >> already fixed. > > > >> > > > >> I propose to prepare the next minor release. Branch was already cut > > and > > > >> commits were cherry-picked [3]. > > > >> > > > >> If there are no objections, I will prepare a release and will start > > voting > > > >> thread in a day or two. > > > >> > > > >> [1] -- https://issues.apache.org/jira/browse/IGNITE-15479 > > > >> [2] -- > > > >> > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20python-0.5.2 > > > >> [3] -- > > > >> > > > https://github.com/apache/ignite-python-thin-client/commits/pyignite-0.5.2 > > > >> > > > > > > > > > > > > -- > > > > Sincerely yours, Ivan Daschinskiy > > > > > > -- Sincerely yours, Ivan Daschinskiy
Re: Release of pyignite 0.5.2 proposal
+1 Best Regards, Igor On Thu, Sep 9, 2021 at 8:33 PM Maxim Muzafarov wrote: > +1 > > On Thu, 9 Sept 2021 at 14:08, Nikolay Izhikov wrote: > > > > +1 to release ASAP. > > > > > 9 сент. 2021 г., в 13:43, Ivan Daschinsky > написал(а): > > > > > > TC build of release branch -- > > > > https://tc.sbt-ignite-dev.ru/buildConfiguration/IgniteThinClients_Tests_ThinClientPython/6130289 > > > > > > чт, 9 сент. 2021 г. в 13:40, Ivan Daschinsky : > > > > > >> Hi, folks. > > >> > > >> Unfortunately, a quite severe bug found in pyignite since 0.4.0 was > found > > >> [1]. Fortunately, it is already fixed. Also there are also a few bugs > > >> already fixed. > > >> > > >> I propose to prepare the next minor release. Branch was already cut > and > > >> commits were cherry-picked [3]. > > >> > > >> If there are no objections, I will prepare a release and will start > voting > > >> thread in a day or two. > > >> > > >> [1] -- https://issues.apache.org/jira/browse/IGNITE-15479 > > >> [2] -- > > >> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20python-0.5.2 > > >> [3] -- > > >> > https://github.com/apache/ignite-python-thin-client/commits/pyignite-0.5.2 > > >> > > > > > > > > > -- > > > Sincerely yours, Ivan Daschinskiy > > >
Re: Release of pyignite 0.5.2 proposal
+1 On Thu, 9 Sept 2021 at 14:08, Nikolay Izhikov wrote: > > +1 to release ASAP. > > > 9 сент. 2021 г., в 13:43, Ivan Daschinsky написал(а): > > > > TC build of release branch -- > > https://tc.sbt-ignite-dev.ru/buildConfiguration/IgniteThinClients_Tests_ThinClientPython/6130289 > > > > чт, 9 сент. 2021 г. в 13:40, Ivan Daschinsky : > > > >> Hi, folks. > >> > >> Unfortunately, a quite severe bug found in pyignite since 0.4.0 was found > >> [1]. Fortunately, it is already fixed. Also there are also a few bugs > >> already fixed. > >> > >> I propose to prepare the next minor release. Branch was already cut and > >> commits were cherry-picked [3]. > >> > >> If there are no objections, I will prepare a release and will start voting > >> thread in a day or two. > >> > >> [1] -- https://issues.apache.org/jira/browse/IGNITE-15479 > >> [2] -- > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20python-0.5.2 > >> [3] -- > >> https://github.com/apache/ignite-python-thin-client/commits/pyignite-0.5.2 > >> > > > > > > -- > > Sincerely yours, Ivan Daschinskiy >
Re: Release of pyignite 0.5.2 proposal
+1 to release ASAP. > 9 сент. 2021 г., в 13:43, Ivan Daschinsky написал(а): > > TC build of release branch -- > https://tc.sbt-ignite-dev.ru/buildConfiguration/IgniteThinClients_Tests_ThinClientPython/6130289 > > чт, 9 сент. 2021 г. в 13:40, Ivan Daschinsky : > >> Hi, folks. >> >> Unfortunately, a quite severe bug found in pyignite since 0.4.0 was found >> [1]. Fortunately, it is already fixed. Also there are also a few bugs >> already fixed. >> >> I propose to prepare the next minor release. Branch was already cut and >> commits were cherry-picked [3]. >> >> If there are no objections, I will prepare a release and will start voting >> thread in a day or two. >> >> [1] -- https://issues.apache.org/jira/browse/IGNITE-15479 >> [2] -- >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20python-0.5.2 >> [3] -- >> https://github.com/apache/ignite-python-thin-client/commits/pyignite-0.5.2 >> > > > -- > Sincerely yours, Ivan Daschinskiy
Re: Release of pyignite 0.5.2 proposal
TC build of release branch -- https://tc.sbt-ignite-dev.ru/buildConfiguration/IgniteThinClients_Tests_ThinClientPython/6130289 чт, 9 сент. 2021 г. в 13:40, Ivan Daschinsky : > Hi, folks. > > Unfortunately, a quite severe bug found in pyignite since 0.4.0 was found > [1]. Fortunately, it is already fixed. Also there are also a few bugs > already fixed. > > I propose to prepare the next minor release. Branch was already cut and > commits were cherry-picked [3]. > > If there are no objections, I will prepare a release and will start voting > thread in a day or two. > > [1] -- https://issues.apache.org/jira/browse/IGNITE-15479 > [2] -- > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20python-0.5.2 > [3] -- > https://github.com/apache/ignite-python-thin-client/commits/pyignite-0.5.2 > -- Sincerely yours, Ivan Daschinskiy
Release of pyignite 0.5.2 proposal
Hi, folks. Unfortunately, a quite severe bug found in pyignite since 0.4.0 was found [1]. Fortunately, it is already fixed. Also there are also a few bugs already fixed. I propose to prepare the next minor release. Branch was already cut and commits were cherry-picked [3]. If there are no objections, I will prepare a release and will start voting thread in a day or two. [1] -- https://issues.apache.org/jira/browse/IGNITE-15479 [2] -- https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20python-0.5.2 [3] -- https://github.com/apache/ignite-python-thin-client/commits/pyignite-0.5.2
Re: Proposal to remove explicit "GC disable" startup suggestion
Ilya, hi. +1 from me. We should not worry about weird user actions. Direct calling of GC looks unusual today. Suggestion of forced disabling manual System.gc() looks useless. 14.05.2021 15:06, Ilya Korol пишет: Hi, everyone. There is a proposal to remove suggestion that user should disable explicit GC calls in https://issues.apache.org/jira/browse/IGNITE-14720. Nowadays people usually don't use this facility directly without huge need (at least we hope so), so this suggestion doesn't bring much profit, but instead could lead to potential problems with reclaiming memory used by direct memory buffers. I'm going to fix this. Is there any objections (suggestions)?
Re: Proposal to remove explicit "GC disable" startup suggestion
Does the document also need to be adjusted? https://ignite.apache.org/docs/latest/perf-and-troubleshooting/memory-tuning 在 2021/5/18 上午1:46, Valentin Kulichenko 写道: Got it. The proposal makes sense to me, let's remove the suggestion. -Val On Sun, May 16, 2021 at 5:50 AM Ilya Korol wrote: In some circumstances there could be a state when direct buffers (instantiated for IO purposes) hold too many memory and to get this memory back JVM calls System.gc() (as was mentioned earlier by Ivan Daschinsky): ByteBuffer.allocateDirect(capacity) new DirectButeBuffer(capacity) Bits.reserveMemory(size, cap) ... System.gc() // if optimistic attempts to reserve required memory failed See also: [1] http://www.mastertheboss.com/other/java-stuff/troubleshooting-outofmemoryerror-direct-buffer-memory See 16.05.2021 01:21, Valentin Kulichenko пишет: Hi Ilya, Out of curiosity - what are the potential problems with memory buffers that you're referring to? -Val On Fri, May 14, 2021 at 5:06 AM Ilya Korol wrote: Hi, everyone. There is a proposal to remove suggestion that user should disable explicit GC calls in https://issues.apache.org/jira/browse/IGNITE-14720 . Nowadays people usually don't use this facility directly without huge need (at least we hope so), so this suggestion doesn't bring much profit, but instead could lead to potential problems with reclaiming memory used by direct memory buffers. I'm going to fix this. Is there any objections (suggestions)?
Re: Proposal to remove explicit "GC disable" startup suggestion
Got it. The proposal makes sense to me, let's remove the suggestion. -Val On Sun, May 16, 2021 at 5:50 AM Ilya Korol wrote: > In some circumstances there could be a state when direct buffers > (instantiated for IO purposes) hold too many memory and to get this > memory back JVM calls System.gc() (as was mentioned earlier by Ivan > Daschinsky): > > ByteBuffer.allocateDirect(capacity) > new DirectButeBuffer(capacity) > Bits.reserveMemory(size, cap) > ... > System.gc() // if optimistic attempts to reserve required > memory failed > > See also: > [1] > > http://www.mastertheboss.com/other/java-stuff/troubleshooting-outofmemoryerror-direct-buffer-memory > > See > > 16.05.2021 01:21, Valentin Kulichenko пишет: > > Hi Ilya, > > > > Out of curiosity - what are the potential problems with memory buffers > that > > you're referring to? > > > > -Val > > > > On Fri, May 14, 2021 at 5:06 AM Ilya Korol wrote: > > > >> Hi, everyone. > >> > >> There is a proposal to remove suggestion that user should disable > >> explicit GC calls in https://issues.apache.org/jira/browse/IGNITE-14720 > . > >> > >> Nowadays people usually don't use this facility directly without huge > >> need (at least we hope so), so this suggestion doesn't bring much > >> profit, but instead could lead to potential problems with reclaiming > >> memory used by direct memory buffers. > >> > >> I'm going to fix this. > >> > >> Is there any objections (suggestions)? > >> > >> >
Re: Proposal to remove explicit "GC disable" startup suggestion
In some circumstances there could be a state when direct buffers (instantiated for IO purposes) hold too many memory and to get this memory back JVM calls System.gc() (as was mentioned earlier by Ivan Daschinsky): ByteBuffer.allocateDirect(capacity) new DirectButeBuffer(capacity) Bits.reserveMemory(size, cap) ... System.gc() // if optimistic attempts to reserve required memory failed See also: [1] http://www.mastertheboss.com/other/java-stuff/troubleshooting-outofmemoryerror-direct-buffer-memory See 16.05.2021 01:21, Valentin Kulichenko пишет: Hi Ilya, Out of curiosity - what are the potential problems with memory buffers that you're referring to? -Val On Fri, May 14, 2021 at 5:06 AM Ilya Korol wrote: Hi, everyone. There is a proposal to remove suggestion that user should disable explicit GC calls in https://issues.apache.org/jira/browse/IGNITE-14720. Nowadays people usually don't use this facility directly without huge need (at least we hope so), so this suggestion doesn't bring much profit, but instead could lead to potential problems with reclaiming memory used by direct memory buffers. I'm going to fix this. Is there any objections (suggestions)?
Re: Proposal to remove explicit "GC disable" startup suggestion
Hi, Val! Please take a look to java.nio.Bits.reserveMemory (jdk8). In this method you can see explicit call of System.gc() вс, 16 мая 2021 г., 01:22 Valentin Kulichenko : > Hi Ilya, > > Out of curiosity - what are the potential problems with memory buffers that > you're referring to? > > -Val > > On Fri, May 14, 2021 at 5:06 AM Ilya Korol wrote: > > > Hi, everyone. > > > > There is a proposal to remove suggestion that user should disable > > explicit GC calls in https://issues.apache.org/jira/browse/IGNITE-14720. > > > > Nowadays people usually don't use this facility directly without huge > > need (at least we hope so), so this suggestion doesn't bring much > > profit, but instead could lead to potential problems with reclaiming > > memory used by direct memory buffers. > > > > I'm going to fix this. > > > > Is there any objections (suggestions)? > > > > >
Re: Proposal to remove explicit "GC disable" startup suggestion
Hi Ilya, Out of curiosity - what are the potential problems with memory buffers that you're referring to? -Val On Fri, May 14, 2021 at 5:06 AM Ilya Korol wrote: > Hi, everyone. > > There is a proposal to remove suggestion that user should disable > explicit GC calls in https://issues.apache.org/jira/browse/IGNITE-14720. > > Nowadays people usually don't use this facility directly without huge > need (at least we hope so), so this suggestion doesn't bring much > profit, but instead could lead to potential problems with reclaiming > memory used by direct memory buffers. > > I'm going to fix this. > > Is there any objections (suggestions)? > >
Proposal to remove explicit "GC disable" startup suggestion
Hi, everyone. There is a proposal to remove suggestion that user should disable explicit GC calls in https://issues.apache.org/jira/browse/IGNITE-14720. Nowadays people usually don't use this facility directly without huge need (at least we hope so), so this suggestion doesn't bring much profit, but instead could lead to potential problems with reclaiming memory used by direct memory buffers. I'm going to fix this. Is there any objections (suggestions)?
Re: 2.9.1 release proposal
Folks, Alexey, Sure, I forgot about the Christmas holidays. I don't think we will be able to complete our release procedures with-in the next few weeks, so let's shift the dates a bit late. Let's prepare everything prior to the holidays and set the TC.Bot for the stabilization period on holidays to catch all the flaky issues. Code Freeze: December 25th, 2020 Release Date: January 18th, 2021 WDYT? On Thu, 5 Nov 2020 at 13:42, Alexey Goncharuk wrote: > > Maxim, > > Should we shift the dates so they are not too close to state holidays in > various countries? I'm concerned we won't be getting much activity around > holidays and people who would otherwise spend some time on testing the > release will not be able to do so. > > чт, 5 нояб. 2020 г. в 12:21, Maxim Muzafarov : > > > Folks, > > > > What may be the comfortable dates of the 2.10 release to finish all > > the related development activities? > > I suggest release Apache Ignite 2.10 prior to the end of this year and > > focus on the 3.0 activities in 2021 with only bug-fix releases for the > > 2.10.x. > > > > I suggest the following release dates for the 2.10: > > > > Code Freeze: December 16th, 2020 > > Release Date: December 30th, 2020 > > > > On Tue, 3 Nov 2020 at 18:15, Yaroslav Molochkov > > wrote: > > > > > > Nikolay, hi! > > > > > > Done. > > > > > > On Tue, Nov 3, 2020 at 10:48 AM Nikolay Izhikov > > wrote: > > > > > > > Hello, Yaroslav. > > > > > > > > Looks like we have fixVersion 2.9.1 in Jira. > > > > Let’s mark all tickets with label «2.9.1-rc1» with fixVersion=2.9.1 and > > > > use fixVersion instead of label further. > > > > > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 > > > > > > > > > 2 нояб. 2020 г., в 19:42, Yaroslav Molochkov > > > > написал(а): > > > > > > > > > > Guys, > > > > > > > > > > should you agree that issues with the 2.9.1-rc tag are good enough > > > > > for a maintenance release, i'd like to give it a go. > > > > > > > > > > On Thu, Oct 29, 2020 at 5:33 PM Alexey Zinoviev < > > zaleslaw@gmail.com> > > > > > wrote: > > > > > > > > > >> Let's discuss the possible planning dates for feature freeze for > > 2.10, > > > > for > > > > >> example? Do you have any plans or ideas? > > > > >> > > > > >> чт, 29 окт. 2020 г. в 17:24, Andrey Gura : > > > > >> > > > > >>> Hi, > > > > >>> > > > > >>> I agree with Alexey. We should release 2.9.1 and start preparing > > for > > > > >>> the 2.10 release. > > > > >>> > > > > >>> 2.x releases usually take a lot of time. So we can release 2.9.1, > > and > > > > >>> even 2.9.2 before 2.10. > > > > >>> > > > > >>> On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk > > > > >>> wrote: > > > > > > > > Hello folks, > > > > > > > > I think we should start both 2.9.1 and 2.10. In practice, > > maintenance > > > > release contains only critical and usability bugfixes (for > > example, I > > > > >>> would > > > > include this ticket [1] to include in 2.9.1 as it prevents users > > from > > > > >>> using > > > > tracing) and is released much faster than a minor release. > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13640 > > > > > > > > вт, 27 окт. 2020 г. в 21:41, Guru Stron < > > gurustronpub...@gmail.com>: > > > > > > > > > Hello, > > > > > > > > > > Agree with Pavel. > > > > > > > > > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn < > > ptupit...@apache.org> > > > > >>> wrote: > > > > > > > > > >> Igniters, > > > > >> > > > > >> I think we should plan 2.10 instead of 2.9.1. > > > > >> ignite-2.9 branch was cut 4 months ago, a bunch of new features > > are > > > > > waiting > > > > >> to be released. > > > > >> > > > > >> On Tue, Oct 27, 2020 at 4:23 AM 18624049226 < > > 18624049...@163.com> > > > > >>> wrote: > > > > >> > > > > >>> Hello, > > > > >>> > > > > >>> I suggest that the remaining document issue in version 2.9.0 > > can > > > > >> be > > > > >>> solved in version 2.9.1, and it is not a good practice to > > > > >> postpone > > > > >>> to > > > > >>> version 2.10. > > > > >>> > > > > >>> 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > > > Hello, > > > > > > > > +1 > > > > Should we start the discussion about the release leader and > > > > >>> release > > > > >>> dates? > > > > > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > > > > > > > wrote: > > > > > +1 to start the 2.9.1 release process once as soon as 2.9 > > > > >>> released. > > > > > > > > > > On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > > > > > nizhi...@apache.org> > > > > >>> wrote: > > > > > > > > > >> Hello, Yaroslav. > > > > >> > > > > >> I support the idea. > > > > >> But, we should carefully work with the release scope. > > > >
Re: 2.9.1 release proposal
Maxim, Should we shift the dates so they are not too close to state holidays in various countries? I'm concerned we won't be getting much activity around holidays and people who would otherwise spend some time on testing the release will not be able to do so. чт, 5 нояб. 2020 г. в 12:21, Maxim Muzafarov : > Folks, > > What may be the comfortable dates of the 2.10 release to finish all > the related development activities? > I suggest release Apache Ignite 2.10 prior to the end of this year and > focus on the 3.0 activities in 2021 with only bug-fix releases for the > 2.10.x. > > I suggest the following release dates for the 2.10: > > Code Freeze: December 16th, 2020 > Release Date: December 30th, 2020 > > On Tue, 3 Nov 2020 at 18:15, Yaroslav Molochkov > wrote: > > > > Nikolay, hi! > > > > Done. > > > > On Tue, Nov 3, 2020 at 10:48 AM Nikolay Izhikov > wrote: > > > > > Hello, Yaroslav. > > > > > > Looks like we have fixVersion 2.9.1 in Jira. > > > Let’s mark all tickets with label «2.9.1-rc1» with fixVersion=2.9.1 and > > > use fixVersion instead of label further. > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 > > > > > > > 2 нояб. 2020 г., в 19:42, Yaroslav Molochkov > > > написал(а): > > > > > > > > Guys, > > > > > > > > should you agree that issues with the 2.9.1-rc tag are good enough > > > > for a maintenance release, i'd like to give it a go. > > > > > > > > On Thu, Oct 29, 2020 at 5:33 PM Alexey Zinoviev < > zaleslaw@gmail.com> > > > > wrote: > > > > > > > >> Let's discuss the possible planning dates for feature freeze for > 2.10, > > > for > > > >> example? Do you have any plans or ideas? > > > >> > > > >> чт, 29 окт. 2020 г. в 17:24, Andrey Gura : > > > >> > > > >>> Hi, > > > >>> > > > >>> I agree with Alexey. We should release 2.9.1 and start preparing > for > > > >>> the 2.10 release. > > > >>> > > > >>> 2.x releases usually take a lot of time. So we can release 2.9.1, > and > > > >>> even 2.9.2 before 2.10. > > > >>> > > > >>> On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk > > > >>> wrote: > > > > > > Hello folks, > > > > > > I think we should start both 2.9.1 and 2.10. In practice, > maintenance > > > release contains only critical and usability bugfixes (for > example, I > > > >>> would > > > include this ticket [1] to include in 2.9.1 as it prevents users > from > > > >>> using > > > tracing) and is released much faster than a minor release. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13640 > > > > > > вт, 27 окт. 2020 г. в 21:41, Guru Stron < > gurustronpub...@gmail.com>: > > > > > > > Hello, > > > > > > > > Agree with Pavel. > > > > > > > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn < > ptupit...@apache.org> > > > >>> wrote: > > > > > > > >> Igniters, > > > >> > > > >> I think we should plan 2.10 instead of 2.9.1. > > > >> ignite-2.9 branch was cut 4 months ago, a bunch of new features > are > > > > waiting > > > >> to be released. > > > >> > > > >> On Tue, Oct 27, 2020 at 4:23 AM 18624049226 < > 18624049...@163.com> > > > >>> wrote: > > > >> > > > >>> Hello, > > > >>> > > > >>> I suggest that the remaining document issue in version 2.9.0 > can > > > >> be > > > >>> solved in version 2.9.1, and it is not a good practice to > > > >> postpone > > > >>> to > > > >>> version 2.10. > > > >>> > > > >>> 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > > Hello, > > > > > > +1 > > > Should we start the discussion about the release leader and > > > >>> release > > > >>> dates? > > > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > > > > > wrote: > > > > +1 to start the 2.9.1 release process once as soon as 2.9 > > > >>> released. > > > > > > > > On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > > > > nizhi...@apache.org> > > > >>> wrote: > > > > > > > >> Hello, Yaroslav. > > > >> > > > >> I support the idea. > > > >> But, we should carefully work with the release scope. > > > >> > > > >> IGNITE-13477 - fix for a SQL tracing that will be available > > > >>> only in > > > >>> 2.10 > > > >> IGNITE-13427 - fix for a new system view that exists in > > > >> master > > > > only, > > > >> we > > > >> need to include IGNITE-13409 > > > >> > > > >> Other tickets should be checked, also. > > > >> Is this a real fix of a released bug or we fix some issue we > > > >>> bring > > > >> with > > > >> the brand new contribution. > > > >> > > > >> > > > >> I propose to include the following tickets, also: > > > >> > > > >> CMD tools improvements: > > > >> > > > >> IGNITE-13488 - Command to print
Re: 2.9.1 release proposal
I'm ok with code freeze dates чт, 5 нояб. 2020 г. в 12:21, Maxim Muzafarov : > Folks, > > What may be the comfortable dates of the 2.10 release to finish all > the related development activities? > I suggest release Apache Ignite 2.10 prior to the end of this year and > focus on the 3.0 activities in 2021 with only bug-fix releases for the > 2.10.x. > > I suggest the following release dates for the 2.10: > > Code Freeze: December 16th, 2020 > Release Date: December 30th, 2020 > > On Tue, 3 Nov 2020 at 18:15, Yaroslav Molochkov > wrote: > > > > Nikolay, hi! > > > > Done. > > > > On Tue, Nov 3, 2020 at 10:48 AM Nikolay Izhikov > wrote: > > > > > Hello, Yaroslav. > > > > > > Looks like we have fixVersion 2.9.1 in Jira. > > > Let’s mark all tickets with label «2.9.1-rc1» with fixVersion=2.9.1 and > > > use fixVersion instead of label further. > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 > > > > > > > 2 нояб. 2020 г., в 19:42, Yaroslav Molochkov > > > написал(а): > > > > > > > > Guys, > > > > > > > > should you agree that issues with the 2.9.1-rc tag are good enough > > > > for a maintenance release, i'd like to give it a go. > > > > > > > > On Thu, Oct 29, 2020 at 5:33 PM Alexey Zinoviev < > zaleslaw@gmail.com> > > > > wrote: > > > > > > > >> Let's discuss the possible planning dates for feature freeze for > 2.10, > > > for > > > >> example? Do you have any plans or ideas? > > > >> > > > >> чт, 29 окт. 2020 г. в 17:24, Andrey Gura : > > > >> > > > >>> Hi, > > > >>> > > > >>> I agree with Alexey. We should release 2.9.1 and start preparing > for > > > >>> the 2.10 release. > > > >>> > > > >>> 2.x releases usually take a lot of time. So we can release 2.9.1, > and > > > >>> even 2.9.2 before 2.10. > > > >>> > > > >>> On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk > > > >>> wrote: > > > > > > Hello folks, > > > > > > I think we should start both 2.9.1 and 2.10. In practice, > maintenance > > > release contains only critical and usability bugfixes (for > example, I > > > >>> would > > > include this ticket [1] to include in 2.9.1 as it prevents users > from > > > >>> using > > > tracing) and is released much faster than a minor release. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13640 > > > > > > вт, 27 окт. 2020 г. в 21:41, Guru Stron < > gurustronpub...@gmail.com>: > > > > > > > Hello, > > > > > > > > Agree with Pavel. > > > > > > > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn < > ptupit...@apache.org> > > > >>> wrote: > > > > > > > >> Igniters, > > > >> > > > >> I think we should plan 2.10 instead of 2.9.1. > > > >> ignite-2.9 branch was cut 4 months ago, a bunch of new features > are > > > > waiting > > > >> to be released. > > > >> > > > >> On Tue, Oct 27, 2020 at 4:23 AM 18624049226 < > 18624049...@163.com> > > > >>> wrote: > > > >> > > > >>> Hello, > > > >>> > > > >>> I suggest that the remaining document issue in version 2.9.0 > can > > > >> be > > > >>> solved in version 2.9.1, and it is not a good practice to > > > >> postpone > > > >>> to > > > >>> version 2.10. > > > >>> > > > >>> 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > > Hello, > > > > > > +1 > > > Should we start the discussion about the release leader and > > > >>> release > > > >>> dates? > > > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > > > > > wrote: > > > > +1 to start the 2.9.1 release process once as soon as 2.9 > > > >>> released. > > > > > > > > On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > > > > nizhi...@apache.org> > > > >>> wrote: > > > > > > > >> Hello, Yaroslav. > > > >> > > > >> I support the idea. > > > >> But, we should carefully work with the release scope. > > > >> > > > >> IGNITE-13477 - fix for a SQL tracing that will be available > > > >>> only in > > > >>> 2.10 > > > >> IGNITE-13427 - fix for a new system view that exists in > > > >> master > > > > only, > > > >> we > > > >> need to include IGNITE-13409 > > > >> > > > >> Other tickets should be checked, also. > > > >> Is this a real fix of a released bug or we fix some issue we > > > >>> bring > > > >> with > > > >> the brand new contribution. > > > >> > > > >> > > > >> I propose to include the following tickets, also: > > > >> > > > >> CMD tools improvements: > > > >> > > > >> IGNITE-13488 - Command to print metric value > > > >> IGNITE-13426 - Command to print system view content > > > >> IGNITE-13422 - Parameter to explicitly enable experimental > > > >>> commands > > > >> > > > >> IGNITE-13380 - Output
Re: 2.9.1 release proposal
Folks, What may be the comfortable dates of the 2.10 release to finish all the related development activities? I suggest release Apache Ignite 2.10 prior to the end of this year and focus on the 3.0 activities in 2021 with only bug-fix releases for the 2.10.x. I suggest the following release dates for the 2.10: Code Freeze: December 16th, 2020 Release Date: December 30th, 2020 On Tue, 3 Nov 2020 at 18:15, Yaroslav Molochkov wrote: > > Nikolay, hi! > > Done. > > On Tue, Nov 3, 2020 at 10:48 AM Nikolay Izhikov wrote: > > > Hello, Yaroslav. > > > > Looks like we have fixVersion 2.9.1 in Jira. > > Let’s mark all tickets with label «2.9.1-rc1» with fixVersion=2.9.1 and > > use fixVersion instead of label further. > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 > > > > > 2 нояб. 2020 г., в 19:42, Yaroslav Molochkov > > написал(а): > > > > > > Guys, > > > > > > should you agree that issues with the 2.9.1-rc tag are good enough > > > for a maintenance release, i'd like to give it a go. > > > > > > On Thu, Oct 29, 2020 at 5:33 PM Alexey Zinoviev > > > wrote: > > > > > >> Let's discuss the possible planning dates for feature freeze for 2.10, > > for > > >> example? Do you have any plans or ideas? > > >> > > >> чт, 29 окт. 2020 г. в 17:24, Andrey Gura : > > >> > > >>> Hi, > > >>> > > >>> I agree with Alexey. We should release 2.9.1 and start preparing for > > >>> the 2.10 release. > > >>> > > >>> 2.x releases usually take a lot of time. So we can release 2.9.1, and > > >>> even 2.9.2 before 2.10. > > >>> > > >>> On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk > > >>> wrote: > > > > Hello folks, > > > > I think we should start both 2.9.1 and 2.10. In practice, maintenance > > release contains only critical and usability bugfixes (for example, I > > >>> would > > include this ticket [1] to include in 2.9.1 as it prevents users from > > >>> using > > tracing) and is released much faster than a minor release. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13640 > > > > вт, 27 окт. 2020 г. в 21:41, Guru Stron : > > > > > Hello, > > > > > > Agree with Pavel. > > > > > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn > > >>> wrote: > > > > > >> Igniters, > > >> > > >> I think we should plan 2.10 instead of 2.9.1. > > >> ignite-2.9 branch was cut 4 months ago, a bunch of new features are > > > waiting > > >> to be released. > > >> > > >> On Tue, Oct 27, 2020 at 4:23 AM 18624049226 <18624049...@163.com> > > >>> wrote: > > >> > > >>> Hello, > > >>> > > >>> I suggest that the remaining document issue in version 2.9.0 can > > >> be > > >>> solved in version 2.9.1, and it is not a good practice to > > >> postpone > > >>> to > > >>> version 2.10. > > >>> > > >>> 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > Hello, > > > > +1 > > Should we start the discussion about the release leader and > > >>> release > > >>> dates? > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > > > wrote: > > > +1 to start the 2.9.1 release process once as soon as 2.9 > > >>> released. > > > > > > On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > > > nizhi...@apache.org> > > >>> wrote: > > > > > >> Hello, Yaroslav. > > >> > > >> I support the idea. > > >> But, we should carefully work with the release scope. > > >> > > >> IGNITE-13477 - fix for a SQL tracing that will be available > > >>> only in > > >>> 2.10 > > >> IGNITE-13427 - fix for a new system view that exists in > > >> master > > > only, > > >> we > > >> need to include IGNITE-13409 > > >> > > >> Other tickets should be checked, also. > > >> Is this a real fix of a released bug or we fix some issue we > > >>> bring > > >> with > > >> the brand new contribution. > > >> > > >> > > >> I propose to include the following tickets, also: > > >> > > >> CMD tools improvements: > > >> > > >> IGNITE-13488 - Command to print metric value > > >> IGNITE-13426 - Command to print system view content > > >> IGNITE-13422 - Parameter to explicitly enable experimental > > >>> commands > > >> > > >> IGNITE-13380 - Output IgniteSystemProperties via ignite.sh > > >> > > >> New system views: > > >> > > >> IGNITE-13409 Metastorage and DistributedMetastorage viewы. > > >> IGNITE-13408 BinaryMetadata view. > > >> > > >> > > >>> 19 окт. 2020 г., в 18:20, Yaroslav Molochkov < > > > molochko...@gmail.com > > >>> > > >> написал(а): > > >>> Hello, Igniters! > > >>> > > >>> I've compiled a list of
Re: 2.9.1 release proposal
Nikolay, hi! Done. On Tue, Nov 3, 2020 at 10:48 AM Nikolay Izhikov wrote: > Hello, Yaroslav. > > Looks like we have fixVersion 2.9.1 in Jira. > Let’s mark all tickets with label «2.9.1-rc1» with fixVersion=2.9.1 and > use fixVersion instead of label further. > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 > > > 2 нояб. 2020 г., в 19:42, Yaroslav Molochkov > написал(а): > > > > Guys, > > > > should you agree that issues with the 2.9.1-rc tag are good enough > > for a maintenance release, i'd like to give it a go. > > > > On Thu, Oct 29, 2020 at 5:33 PM Alexey Zinoviev > > wrote: > > > >> Let's discuss the possible planning dates for feature freeze for 2.10, > for > >> example? Do you have any plans or ideas? > >> > >> чт, 29 окт. 2020 г. в 17:24, Andrey Gura : > >> > >>> Hi, > >>> > >>> I agree with Alexey. We should release 2.9.1 and start preparing for > >>> the 2.10 release. > >>> > >>> 2.x releases usually take a lot of time. So we can release 2.9.1, and > >>> even 2.9.2 before 2.10. > >>> > >>> On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk > >>> wrote: > > Hello folks, > > I think we should start both 2.9.1 and 2.10. In practice, maintenance > release contains only critical and usability bugfixes (for example, I > >>> would > include this ticket [1] to include in 2.9.1 as it prevents users from > >>> using > tracing) and is released much faster than a minor release. > > [1] https://issues.apache.org/jira/browse/IGNITE-13640 > > вт, 27 окт. 2020 г. в 21:41, Guru Stron : > > > Hello, > > > > Agree with Pavel. > > > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn > >>> wrote: > > > >> Igniters, > >> > >> I think we should plan 2.10 instead of 2.9.1. > >> ignite-2.9 branch was cut 4 months ago, a bunch of new features are > > waiting > >> to be released. > >> > >> On Tue, Oct 27, 2020 at 4:23 AM 18624049226 <18624049...@163.com> > >>> wrote: > >> > >>> Hello, > >>> > >>> I suggest that the remaining document issue in version 2.9.0 can > >> be > >>> solved in version 2.9.1, and it is not a good practice to > >> postpone > >>> to > >>> version 2.10. > >>> > >>> 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > Hello, > > +1 > Should we start the discussion about the release leader and > >>> release > >>> dates? > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > > wrote: > > +1 to start the 2.9.1 release process once as soon as 2.9 > >>> released. > > > > On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > > nizhi...@apache.org> > >>> wrote: > > > >> Hello, Yaroslav. > >> > >> I support the idea. > >> But, we should carefully work with the release scope. > >> > >> IGNITE-13477 - fix for a SQL tracing that will be available > >>> only in > >>> 2.10 > >> IGNITE-13427 - fix for a new system view that exists in > >> master > > only, > >> we > >> need to include IGNITE-13409 > >> > >> Other tickets should be checked, also. > >> Is this a real fix of a released bug or we fix some issue we > >>> bring > >> with > >> the brand new contribution. > >> > >> > >> I propose to include the following tickets, also: > >> > >> CMD tools improvements: > >> > >> IGNITE-13488 - Command to print metric value > >> IGNITE-13426 - Command to print system view content > >> IGNITE-13422 - Parameter to explicitly enable experimental > >>> commands > >> > >> IGNITE-13380 - Output IgniteSystemProperties via ignite.sh > >> > >> New system views: > >> > >> IGNITE-13409 Metastorage and DistributedMetastorage viewы. > >> IGNITE-13408 BinaryMetadata view. > >> > >> > >>> 19 окт. 2020 г., в 18:20, Yaroslav Molochkov < > > molochko...@gmail.com > >>> > >> написал(а): > >>> Hello, Igniters! > >>> > >>> I've compiled a list of tickets that, i think, deserve to be > >> released > >>> in > >> a > >>> minor Ignite release (meaning in 2.9.1) after 2.9. Here they > >>> are: > >>> > >>> IGNITE-13569 > >>> disable archiving + walCompactionEnabled probably broke > >>> reading > > from > >>> wal > >> on > >>> server restart > >>> > >>> IGNITE-13418 > >>> Deadlock on multiple cache delete > >>> > >>> IGNITE-13563 > >>> Deserializing IBinaryObject containing an IBinaryObject > >> field > > fails > >>> > >>> IGNITE-13575 > >>> Invalid blocking section in GridNioWorker and > >>> GridNioClientWorker >
Re: 2.9.1 release proposal
Hello, Yaroslav. Looks like we have fixVersion 2.9.1 in Jira. Let’s mark all tickets with label «2.9.1-rc1» with fixVersion=2.9.1 and use fixVersion instead of label further. https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 > 2 нояб. 2020 г., в 19:42, Yaroslav Molochkov > написал(а): > > Guys, > > should you agree that issues with the 2.9.1-rc tag are good enough > for a maintenance release, i'd like to give it a go. > > On Thu, Oct 29, 2020 at 5:33 PM Alexey Zinoviev > wrote: > >> Let's discuss the possible planning dates for feature freeze for 2.10, for >> example? Do you have any plans or ideas? >> >> чт, 29 окт. 2020 г. в 17:24, Andrey Gura : >> >>> Hi, >>> >>> I agree with Alexey. We should release 2.9.1 and start preparing for >>> the 2.10 release. >>> >>> 2.x releases usually take a lot of time. So we can release 2.9.1, and >>> even 2.9.2 before 2.10. >>> >>> On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk >>> wrote: Hello folks, I think we should start both 2.9.1 and 2.10. In practice, maintenance release contains only critical and usability bugfixes (for example, I >>> would include this ticket [1] to include in 2.9.1 as it prevents users from >>> using tracing) and is released much faster than a minor release. [1] https://issues.apache.org/jira/browse/IGNITE-13640 вт, 27 окт. 2020 г. в 21:41, Guru Stron : > Hello, > > Agree with Pavel. > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn >>> wrote: > >> Igniters, >> >> I think we should plan 2.10 instead of 2.9.1. >> ignite-2.9 branch was cut 4 months ago, a bunch of new features are > waiting >> to be released. >> >> On Tue, Oct 27, 2020 at 4:23 AM 18624049226 <18624049...@163.com> >>> wrote: >> >>> Hello, >>> >>> I suggest that the remaining document issue in version 2.9.0 can >> be >>> solved in version 2.9.1, and it is not a good practice to >> postpone >>> to >>> version 2.10. >>> >>> 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: Hello, +1 Should we start the discussion about the release leader and >>> release >>> dates? On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > wrote: > +1 to start the 2.9.1 release process once as soon as 2.9 >>> released. > > On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > nizhi...@apache.org> >>> wrote: > >> Hello, Yaroslav. >> >> I support the idea. >> But, we should carefully work with the release scope. >> >> IGNITE-13477 - fix for a SQL tracing that will be available >>> only in >>> 2.10 >> IGNITE-13427 - fix for a new system view that exists in >> master > only, >> we >> need to include IGNITE-13409 >> >> Other tickets should be checked, also. >> Is this a real fix of a released bug or we fix some issue we >>> bring >> with >> the brand new contribution. >> >> >> I propose to include the following tickets, also: >> >> CMD tools improvements: >> >> IGNITE-13488 - Command to print metric value >> IGNITE-13426 - Command to print system view content >> IGNITE-13422 - Parameter to explicitly enable experimental >>> commands >> >> IGNITE-13380 - Output IgniteSystemProperties via ignite.sh >> >> New system views: >> >> IGNITE-13409 Metastorage and DistributedMetastorage viewы. >> IGNITE-13408 BinaryMetadata view. >> >> >>> 19 окт. 2020 г., в 18:20, Yaroslav Molochkov < > molochko...@gmail.com >>> >> написал(а): >>> Hello, Igniters! >>> >>> I've compiled a list of tickets that, i think, deserve to be >> released >>> in >> a >>> minor Ignite release (meaning in 2.9.1) after 2.9. Here they >>> are: >>> >>> IGNITE-13569 >>> disable archiving + walCompactionEnabled probably broke >>> reading > from >>> wal >> on >>> server restart >>> >>> IGNITE-13418 >>> Deadlock on multiple cache delete >>> >>> IGNITE-13563 >>> Deserializing IBinaryObject containing an IBinaryObject >> field > fails >>> >>> IGNITE-13575 >>> Invalid blocking section in GridNioWorker and >>> GridNioClientWorker >>> leads >> to >>> false positive blocking thread detection >>> >>> IGNITE-13458 >>> RebalancingPartitionsTotal metrics >>> >>> IGNITE-13536 >>> .NET: Child processes become zombies when persistence is >> used >>> with >>> direct-io on Linux >>> >>> IGNITE-13500
Re: 2.9.1 release proposal
Guys, should you agree that issues with the 2.9.1-rc tag are good enough for a maintenance release, i'd like to give it a go. On Thu, Oct 29, 2020 at 5:33 PM Alexey Zinoviev wrote: > Let's discuss the possible planning dates for feature freeze for 2.10, for > example? Do you have any plans or ideas? > > чт, 29 окт. 2020 г. в 17:24, Andrey Gura : > > > Hi, > > > > I agree with Alexey. We should release 2.9.1 and start preparing for > > the 2.10 release. > > > > 2.x releases usually take a lot of time. So we can release 2.9.1, and > > even 2.9.2 before 2.10. > > > > On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk > > wrote: > > > > > > Hello folks, > > > > > > I think we should start both 2.9.1 and 2.10. In practice, maintenance > > > release contains only critical and usability bugfixes (for example, I > > would > > > include this ticket [1] to include in 2.9.1 as it prevents users from > > using > > > tracing) and is released much faster than a minor release. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13640 > > > > > > вт, 27 окт. 2020 г. в 21:41, Guru Stron : > > > > > > > Hello, > > > > > > > > Agree with Pavel. > > > > > > > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn > > wrote: > > > > > > > > > Igniters, > > > > > > > > > > I think we should plan 2.10 instead of 2.9.1. > > > > > ignite-2.9 branch was cut 4 months ago, a bunch of new features are > > > > waiting > > > > > to be released. > > > > > > > > > > On Tue, Oct 27, 2020 at 4:23 AM 18624049226 <18624049...@163.com> > > wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > I suggest that the remaining document issue in version 2.9.0 can > be > > > > > > solved in version 2.9.1, and it is not a good practice to > postpone > > to > > > > > > version 2.10. > > > > > > > > > > > > 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > > > > > > Hello, > > > > > > > > > > > > > > +1 > > > > > > > Should we start the discussion about the release leader and > > release > > > > > > dates? > > > > > > > > > > > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > > > > wrote: > > > > > > >> +1 to start the 2.9.1 release process once as soon as 2.9 > > released. > > > > > > >> > > > > > > >> On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > > > > nizhi...@apache.org> > > > > > > wrote: > > > > > > >> > > > > > > >>> Hello, Yaroslav. > > > > > > >>> > > > > > > >>> I support the idea. > > > > > > >>> But, we should carefully work with the release scope. > > > > > > >>> > > > > > > >>> IGNITE-13477 - fix for a SQL tracing that will be available > > only in > > > > > > 2.10 > > > > > > >>> IGNITE-13427 - fix for a new system view that exists in > master > > > > only, > > > > > we > > > > > > >>> need to include IGNITE-13409 > > > > > > >>> > > > > > > >>> Other tickets should be checked, also. > > > > > > >>> Is this a real fix of a released bug or we fix some issue we > > bring > > > > > with > > > > > > >>> the brand new contribution. > > > > > > >>> > > > > > > >>> > > > > > > >>> I propose to include the following tickets, also: > > > > > > >>> > > > > > > >>> CMD tools improvements: > > > > > > >>> > > > > > > >>> IGNITE-13488 - Command to print metric value > > > > > > >>> IGNITE-13426 - Command to print system view content > > > > > > >>> IGNITE-13422 - Parameter to explicitly enable experimental > > commands > > > > > > >>> > > > > > > >>> IGNITE-13380 - Output IgniteSystemProperties via ignite.sh > > > > > > >>> > > > > > > >>> New system views: > > > > > > >>> > > > > > > >>> IGNITE-13409 Metastorage and DistributedMetastorage viewы. > > > > > > >>> IGNITE-13408 BinaryMetadata view. > > > > > > >>> > > > > > > >>> > > > > > > 19 окт. 2020 г., в 18:20, Yaroslav Molochkov < > > > > molochko...@gmail.com > > > > > > > > > > > > >>> написал(а): > > > > > > Hello, Igniters! > > > > > > > > > > > > I've compiled a list of tickets that, i think, deserve to be > > > > > released > > > > > > in > > > > > > >>> a > > > > > > minor Ignite release (meaning in 2.9.1) after 2.9. Here they > > are: > > > > > > > > > > > > IGNITE-13569 > > > > > > disable archiving + walCompactionEnabled probably broke > > reading > > > > from > > > > > > wal > > > > > > >>> on > > > > > > server restart > > > > > > > > > > > > IGNITE-13418 > > > > > > Deadlock on multiple cache delete > > > > > > > > > > > > IGNITE-13563 > > > > > > Deserializing IBinaryObject containing an IBinaryObject > field > > > > fails > > > > > > > > > > > > IGNITE-13575 > > > > > > Invalid blocking section in GridNioWorker and > > GridNioClientWorker > > > > > > leads > > > > > > >>> to > > > > > > false positive blocking thread detection > > > > > > > > > > > > IGNITE-13458 > > > > > > RebalancingPartitionsTotal metrics > > > > > > > > > > > > IGNITE-13536 > > > > > > .NET: Child processes become zombies when persistence is > used > > with > > > > > >
Re: 2.9.1 release proposal
Let's discuss the possible planning dates for feature freeze for 2.10, for example? Do you have any plans or ideas? чт, 29 окт. 2020 г. в 17:24, Andrey Gura : > Hi, > > I agree with Alexey. We should release 2.9.1 and start preparing for > the 2.10 release. > > 2.x releases usually take a lot of time. So we can release 2.9.1, and > even 2.9.2 before 2.10. > > On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk > wrote: > > > > Hello folks, > > > > I think we should start both 2.9.1 and 2.10. In practice, maintenance > > release contains only critical and usability bugfixes (for example, I > would > > include this ticket [1] to include in 2.9.1 as it prevents users from > using > > tracing) and is released much faster than a minor release. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13640 > > > > вт, 27 окт. 2020 г. в 21:41, Guru Stron : > > > > > Hello, > > > > > > Agree with Pavel. > > > > > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn > wrote: > > > > > > > Igniters, > > > > > > > > I think we should plan 2.10 instead of 2.9.1. > > > > ignite-2.9 branch was cut 4 months ago, a bunch of new features are > > > waiting > > > > to be released. > > > > > > > > On Tue, Oct 27, 2020 at 4:23 AM 18624049226 <18624049...@163.com> > wrote: > > > > > > > > > Hello, > > > > > > > > > > I suggest that the remaining document issue in version 2.9.0 can be > > > > > solved in version 2.9.1, and it is not a good practice to postpone > to > > > > > version 2.10. > > > > > > > > > > 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > > > > > Hello, > > > > > > > > > > > > +1 > > > > > > Should we start the discussion about the release leader and > release > > > > > dates? > > > > > > > > > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > > > wrote: > > > > > >> +1 to start the 2.9.1 release process once as soon as 2.9 > released. > > > > > >> > > > > > >> On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > > > nizhi...@apache.org> > > > > > wrote: > > > > > >> > > > > > >>> Hello, Yaroslav. > > > > > >>> > > > > > >>> I support the idea. > > > > > >>> But, we should carefully work with the release scope. > > > > > >>> > > > > > >>> IGNITE-13477 - fix for a SQL tracing that will be available > only in > > > > > 2.10 > > > > > >>> IGNITE-13427 - fix for a new system view that exists in master > > > only, > > > > we > > > > > >>> need to include IGNITE-13409 > > > > > >>> > > > > > >>> Other tickets should be checked, also. > > > > > >>> Is this a real fix of a released bug or we fix some issue we > bring > > > > with > > > > > >>> the brand new contribution. > > > > > >>> > > > > > >>> > > > > > >>> I propose to include the following tickets, also: > > > > > >>> > > > > > >>> CMD tools improvements: > > > > > >>> > > > > > >>> IGNITE-13488 - Command to print metric value > > > > > >>> IGNITE-13426 - Command to print system view content > > > > > >>> IGNITE-13422 - Parameter to explicitly enable experimental > commands > > > > > >>> > > > > > >>> IGNITE-13380 - Output IgniteSystemProperties via ignite.sh > > > > > >>> > > > > > >>> New system views: > > > > > >>> > > > > > >>> IGNITE-13409 Metastorage and DistributedMetastorage viewы. > > > > > >>> IGNITE-13408 BinaryMetadata view. > > > > > >>> > > > > > >>> > > > > > 19 окт. 2020 г., в 18:20, Yaroslav Molochkov < > > > molochko...@gmail.com > > > > > > > > > > >>> написал(а): > > > > > Hello, Igniters! > > > > > > > > > > I've compiled a list of tickets that, i think, deserve to be > > > > released > > > > > in > > > > > >>> a > > > > > minor Ignite release (meaning in 2.9.1) after 2.9. Here they > are: > > > > > > > > > > IGNITE-13569 > > > > > disable archiving + walCompactionEnabled probably broke > reading > > > from > > > > > wal > > > > > >>> on > > > > > server restart > > > > > > > > > > IGNITE-13418 > > > > > Deadlock on multiple cache delete > > > > > > > > > > IGNITE-13563 > > > > > Deserializing IBinaryObject containing an IBinaryObject field > > > fails > > > > > > > > > > IGNITE-13575 > > > > > Invalid blocking section in GridNioWorker and > GridNioClientWorker > > > > > leads > > > > > >>> to > > > > > false positive blocking thread detection > > > > > > > > > > IGNITE-13458 > > > > > RebalancingPartitionsTotal metrics > > > > > > > > > > IGNITE-13536 > > > > > .NET: Child processes become zombies when persistence is used > with > > > > > direct-io on Linux > > > > > > > > > > IGNITE-13500 > > > > > Checkpoint read lock fail if it is taking under write lock > during > > > > the > > > > > stopping node > > > > > > > > > > IGNITE-13431 > > > > > NPE during Cassandra Store initialization with PRIMITIVE > strategy > > > > > > > > > > IGNITE-13417 > > > > > Cache Interceptors deserialization on client nodes > > > > > > > > > > IGNITE-13495 > > > > >
Re: 2.9.1 release proposal
Hi, I agree with Alexey. We should release 2.9.1 and start preparing for the 2.10 release. 2.x releases usually take a lot of time. So we can release 2.9.1, and even 2.9.2 before 2.10. On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk wrote: > > Hello folks, > > I think we should start both 2.9.1 and 2.10. In practice, maintenance > release contains only critical and usability bugfixes (for example, I would > include this ticket [1] to include in 2.9.1 as it prevents users from using > tracing) and is released much faster than a minor release. > > [1] https://issues.apache.org/jira/browse/IGNITE-13640 > > вт, 27 окт. 2020 г. в 21:41, Guru Stron : > > > Hello, > > > > Agree with Pavel. > > > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn wrote: > > > > > Igniters, > > > > > > I think we should plan 2.10 instead of 2.9.1. > > > ignite-2.9 branch was cut 4 months ago, a bunch of new features are > > waiting > > > to be released. > > > > > > On Tue, Oct 27, 2020 at 4:23 AM 18624049226 <18624049...@163.com> wrote: > > > > > > > Hello, > > > > > > > > I suggest that the remaining document issue in version 2.9.0 can be > > > > solved in version 2.9.1, and it is not a good practice to postpone to > > > > version 2.10. > > > > > > > > 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > > > > Hello, > > > > > > > > > > +1 > > > > > Should we start the discussion about the release leader and release > > > > dates? > > > > > > > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > > wrote: > > > > >> +1 to start the 2.9.1 release process once as soon as 2.9 released. > > > > >> > > > > >> On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > > nizhi...@apache.org> > > > > wrote: > > > > >> > > > > >>> Hello, Yaroslav. > > > > >>> > > > > >>> I support the idea. > > > > >>> But, we should carefully work with the release scope. > > > > >>> > > > > >>> IGNITE-13477 - fix for a SQL tracing that will be available only in > > > > 2.10 > > > > >>> IGNITE-13427 - fix for a new system view that exists in master > > only, > > > we > > > > >>> need to include IGNITE-13409 > > > > >>> > > > > >>> Other tickets should be checked, also. > > > > >>> Is this a real fix of a released bug or we fix some issue we bring > > > with > > > > >>> the brand new contribution. > > > > >>> > > > > >>> > > > > >>> I propose to include the following tickets, also: > > > > >>> > > > > >>> CMD tools improvements: > > > > >>> > > > > >>> IGNITE-13488 - Command to print metric value > > > > >>> IGNITE-13426 - Command to print system view content > > > > >>> IGNITE-13422 - Parameter to explicitly enable experimental commands > > > > >>> > > > > >>> IGNITE-13380 - Output IgniteSystemProperties via ignite.sh > > > > >>> > > > > >>> New system views: > > > > >>> > > > > >>> IGNITE-13409 Metastorage and DistributedMetastorage viewы. > > > > >>> IGNITE-13408 BinaryMetadata view. > > > > >>> > > > > >>> > > > > 19 окт. 2020 г., в 18:20, Yaroslav Molochkov < > > molochko...@gmail.com > > > > > > > > >>> написал(а): > > > > Hello, Igniters! > > > > > > > > I've compiled a list of tickets that, i think, deserve to be > > > released > > > > in > > > > >>> a > > > > minor Ignite release (meaning in 2.9.1) after 2.9. Here they are: > > > > > > > > IGNITE-13569 > > > > disable archiving + walCompactionEnabled probably broke reading > > from > > > > wal > > > > >>> on > > > > server restart > > > > > > > > IGNITE-13418 > > > > Deadlock on multiple cache delete > > > > > > > > IGNITE-13563 > > > > Deserializing IBinaryObject containing an IBinaryObject field > > fails > > > > > > > > IGNITE-13575 > > > > Invalid blocking section in GridNioWorker and GridNioClientWorker > > > > leads > > > > >>> to > > > > false positive blocking thread detection > > > > > > > > IGNITE-13458 > > > > RebalancingPartitionsTotal metrics > > > > > > > > IGNITE-13536 > > > > .NET: Child processes become zombies when persistence is used with > > > > direct-io on Linux > > > > > > > > IGNITE-13500 > > > > Checkpoint read lock fail if it is taking under write lock during > > > the > > > > stopping node > > > > > > > > IGNITE-13431 > > > > NPE during Cassandra Store initialization with PRIMITIVE strategy > > > > > > > > IGNITE-13417 > > > > Cache Interceptors deserialization on client nodes > > > > > > > > IGNITE-13495 > > > > ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid > > > node > > > > as > > > > coordinator > > > > > > > > IGNITE-13479 > > > > Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh > > > > doesn't > > > > start if JMX port was set > > > > > > > > IGNITE-11312 > > > > JDBC: Thin driver reports incorrect property names > > > > > > > > IGNITE-13462 > > > > .NET: Thin client Dispose hangs when
Re: 2.9.1 release proposal
Hello folks, I think we should start both 2.9.1 and 2.10. In practice, maintenance release contains only critical and usability bugfixes (for example, I would include this ticket [1] to include in 2.9.1 as it prevents users from using tracing) and is released much faster than a minor release. [1] https://issues.apache.org/jira/browse/IGNITE-13640 вт, 27 окт. 2020 г. в 21:41, Guru Stron : > Hello, > > Agree with Pavel. > > On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn wrote: > > > Igniters, > > > > I think we should plan 2.10 instead of 2.9.1. > > ignite-2.9 branch was cut 4 months ago, a bunch of new features are > waiting > > to be released. > > > > On Tue, Oct 27, 2020 at 4:23 AM 18624049226 <18624049...@163.com> wrote: > > > > > Hello, > > > > > > I suggest that the remaining document issue in version 2.9.0 can be > > > solved in version 2.9.1, and it is not a good practice to postpone to > > > version 2.10. > > > > > > 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > > > Hello, > > > > > > > > +1 > > > > Should we start the discussion about the release leader and release > > > dates? > > > > > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov > wrote: > > > >> +1 to start the 2.9.1 release process once as soon as 2.9 released. > > > >> > > > >> On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov < > nizhi...@apache.org> > > > wrote: > > > >> > > > >>> Hello, Yaroslav. > > > >>> > > > >>> I support the idea. > > > >>> But, we should carefully work with the release scope. > > > >>> > > > >>> IGNITE-13477 - fix for a SQL tracing that will be available only in > > > 2.10 > > > >>> IGNITE-13427 - fix for a new system view that exists in master > only, > > we > > > >>> need to include IGNITE-13409 > > > >>> > > > >>> Other tickets should be checked, also. > > > >>> Is this a real fix of a released bug or we fix some issue we bring > > with > > > >>> the brand new contribution. > > > >>> > > > >>> > > > >>> I propose to include the following tickets, also: > > > >>> > > > >>> CMD tools improvements: > > > >>> > > > >>> IGNITE-13488 - Command to print metric value > > > >>> IGNITE-13426 - Command to print system view content > > > >>> IGNITE-13422 - Parameter to explicitly enable experimental commands > > > >>> > > > >>> IGNITE-13380 - Output IgniteSystemProperties via ignite.sh > > > >>> > > > >>> New system views: > > > >>> > > > >>> IGNITE-13409 Metastorage and DistributedMetastorage viewы. > > > >>> IGNITE-13408 BinaryMetadata view. > > > >>> > > > >>> > > > 19 окт. 2020 г., в 18:20, Yaroslav Molochkov < > molochko...@gmail.com > > > > > > >>> написал(а): > > > Hello, Igniters! > > > > > > I've compiled a list of tickets that, i think, deserve to be > > released > > > in > > > >>> a > > > minor Ignite release (meaning in 2.9.1) after 2.9. Here they are: > > > > > > IGNITE-13569 > > > disable archiving + walCompactionEnabled probably broke reading > from > > > wal > > > >>> on > > > server restart > > > > > > IGNITE-13418 > > > Deadlock on multiple cache delete > > > > > > IGNITE-13563 > > > Deserializing IBinaryObject containing an IBinaryObject field > fails > > > > > > IGNITE-13575 > > > Invalid blocking section in GridNioWorker and GridNioClientWorker > > > leads > > > >>> to > > > false positive blocking thread detection > > > > > > IGNITE-13458 > > > RebalancingPartitionsTotal metrics > > > > > > IGNITE-13536 > > > .NET: Child processes become zombies when persistence is used with > > > direct-io on Linux > > > > > > IGNITE-13500 > > > Checkpoint read lock fail if it is taking under write lock during > > the > > > stopping node > > > > > > IGNITE-13431 > > > NPE during Cassandra Store initialization with PRIMITIVE strategy > > > > > > IGNITE-13417 > > > Cache Interceptors deserialization on client nodes > > > > > > IGNITE-13495 > > > ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid > > node > > > as > > > coordinator > > > > > > IGNITE-13479 > > > Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh > > > doesn't > > > start if JMX port was set > > > > > > IGNITE-11312 > > > JDBC: Thin driver reports incorrect property names > > > > > > IGNITE-13462 > > > .NET: Thin client Dispose hangs when continuous query is active on > > > .NET > > > Core 3.x > > > > > > IGNITE-13484 > > > C++ odbc-example losing some values if run with 1 additional node > > > > > > IGNITE-13477 > > > Fix NPE in SQL tracing implementation. > > > > > > IGNITE-13435 > > > Fixing some unrecorded issues command warm-up control.sh > > > > > > IGNITE-13403 > > > Update JDBC metadata to match actual capabilities > > > > > > IGNITE-13427 > > > The local metastorage system view fails if
Re: 2.9.1 release proposal
Hello, Agree with Pavel. On Tue, 27 Oct 2020 at 19:22, Pavel Tupitsyn wrote: > Igniters, > > I think we should plan 2.10 instead of 2.9.1. > ignite-2.9 branch was cut 4 months ago, a bunch of new features are waiting > to be released. > > On Tue, Oct 27, 2020 at 4:23 AM 18624049226 <18624049...@163.com> wrote: > > > Hello, > > > > I suggest that the remaining document issue in version 2.9.0 can be > > solved in version 2.9.1, and it is not a good practice to postpone to > > version 2.10. > > > > 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > > Hello, > > > > > > +1 > > > Should we start the discussion about the release leader and release > > dates? > > > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov wrote: > > >> +1 to start the 2.9.1 release process once as soon as 2.9 released. > > >> > > >> On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov > > wrote: > > >> > > >>> Hello, Yaroslav. > > >>> > > >>> I support the idea. > > >>> But, we should carefully work with the release scope. > > >>> > > >>> IGNITE-13477 - fix for a SQL tracing that will be available only in > > 2.10 > > >>> IGNITE-13427 - fix for a new system view that exists in master only, > we > > >>> need to include IGNITE-13409 > > >>> > > >>> Other tickets should be checked, also. > > >>> Is this a real fix of a released bug or we fix some issue we bring > with > > >>> the brand new contribution. > > >>> > > >>> > > >>> I propose to include the following tickets, also: > > >>> > > >>> CMD tools improvements: > > >>> > > >>> IGNITE-13488 - Command to print metric value > > >>> IGNITE-13426 - Command to print system view content > > >>> IGNITE-13422 - Parameter to explicitly enable experimental commands > > >>> > > >>> IGNITE-13380 - Output IgniteSystemProperties via ignite.sh > > >>> > > >>> New system views: > > >>> > > >>> IGNITE-13409 Metastorage and DistributedMetastorage viewы. > > >>> IGNITE-13408 BinaryMetadata view. > > >>> > > >>> > > 19 окт. 2020 г., в 18:20, Yaroslav Molochkov > > > >>> написал(а): > > Hello, Igniters! > > > > I've compiled a list of tickets that, i think, deserve to be > released > > in > > >>> a > > minor Ignite release (meaning in 2.9.1) after 2.9. Here they are: > > > > IGNITE-13569 > > disable archiving + walCompactionEnabled probably broke reading from > > wal > > >>> on > > server restart > > > > IGNITE-13418 > > Deadlock on multiple cache delete > > > > IGNITE-13563 > > Deserializing IBinaryObject containing an IBinaryObject field fails > > > > IGNITE-13575 > > Invalid blocking section in GridNioWorker and GridNioClientWorker > > leads > > >>> to > > false positive blocking thread detection > > > > IGNITE-13458 > > RebalancingPartitionsTotal metrics > > > > IGNITE-13536 > > .NET: Child processes become zombies when persistence is used with > > direct-io on Linux > > > > IGNITE-13500 > > Checkpoint read lock fail if it is taking under write lock during > the > > stopping node > > > > IGNITE-13431 > > NPE during Cassandra Store initialization with PRIMITIVE strategy > > > > IGNITE-13417 > > Cache Interceptors deserialization on client nodes > > > > IGNITE-13495 > > ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid > node > > as > > coordinator > > > > IGNITE-13479 > > Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh > > doesn't > > start if JMX port was set > > > > IGNITE-11312 > > JDBC: Thin driver reports incorrect property names > > > > IGNITE-13462 > > .NET: Thin client Dispose hangs when continuous query is active on > > .NET > > Core 3.x > > > > IGNITE-13484 > > C++ odbc-example losing some values if run with 1 additional node > > > > IGNITE-13477 > > Fix NPE in SQL tracing implementation. > > > > IGNITE-13435 > > Fixing some unrecorded issues command warm-up control.sh > > > > IGNITE-13403 > > Update JDBC metadata to match actual capabilities > > > > IGNITE-13427 > > The local metastorage system view fails if unmarshallable values > > present > > > > IGNITE-13401 > > Unsupported protocol version exception when getting cache > > configuration > > from Java thin client > > > > IGNITE-13388 > > apache-ignite deb package depends on a non-existent package and > can't > > be > > installed on Debian 10 > > > > IGNITE-13397 > > NPE in logSupplierDone(UUID nodeId) > > > > IGNITE-13296 > > .NET: TransactionImpl finalizer can crash the process > > > > IGNITE-13382 > > DurableBackgroundTask can abandon incomplete task > > > > IGNITE-12509 > > CACHE_REBALANCE_STOPPED event raises for wrong caches in case of > > >>> specified > > RebalanceDelay > >
Re: 2.9.1 release proposal
Igniters, I think we should plan 2.10 instead of 2.9.1. ignite-2.9 branch was cut 4 months ago, a bunch of new features are waiting to be released. On Tue, Oct 27, 2020 at 4:23 AM 18624049226 <18624049...@163.com> wrote: > Hello, > > I suggest that the remaining document issue in version 2.9.0 can be > solved in version 2.9.1, and it is not a good practice to postpone to > version 2.10. > > 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: > > Hello, > > > > +1 > > Should we start the discussion about the release leader and release > dates? > > > > On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov wrote: > >> +1 to start the 2.9.1 release process once as soon as 2.9 released. > >> > >> On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov > wrote: > >> > >>> Hello, Yaroslav. > >>> > >>> I support the idea. > >>> But, we should carefully work with the release scope. > >>> > >>> IGNITE-13477 - fix for a SQL tracing that will be available only in > 2.10 > >>> IGNITE-13427 - fix for a new system view that exists in master only, we > >>> need to include IGNITE-13409 > >>> > >>> Other tickets should be checked, also. > >>> Is this a real fix of a released bug or we fix some issue we bring with > >>> the brand new contribution. > >>> > >>> > >>> I propose to include the following tickets, also: > >>> > >>> CMD tools improvements: > >>> > >>> IGNITE-13488 - Command to print metric value > >>> IGNITE-13426 - Command to print system view content > >>> IGNITE-13422 - Parameter to explicitly enable experimental commands > >>> > >>> IGNITE-13380 - Output IgniteSystemProperties via ignite.sh > >>> > >>> New system views: > >>> > >>> IGNITE-13409 Metastorage and DistributedMetastorage viewы. > >>> IGNITE-13408 BinaryMetadata view. > >>> > >>> > 19 окт. 2020 г., в 18:20, Yaroslav Molochkov > >>> написал(а): > Hello, Igniters! > > I've compiled a list of tickets that, i think, deserve to be released > in > >>> a > minor Ignite release (meaning in 2.9.1) after 2.9. Here they are: > > IGNITE-13569 > disable archiving + walCompactionEnabled probably broke reading from > wal > >>> on > server restart > > IGNITE-13418 > Deadlock on multiple cache delete > > IGNITE-13563 > Deserializing IBinaryObject containing an IBinaryObject field fails > > IGNITE-13575 > Invalid blocking section in GridNioWorker and GridNioClientWorker > leads > >>> to > false positive blocking thread detection > > IGNITE-13458 > RebalancingPartitionsTotal metrics > > IGNITE-13536 > .NET: Child processes become zombies when persistence is used with > direct-io on Linux > > IGNITE-13500 > Checkpoint read lock fail if it is taking under write lock during the > stopping node > > IGNITE-13431 > NPE during Cassandra Store initialization with PRIMITIVE strategy > > IGNITE-13417 > Cache Interceptors deserialization on client nodes > > IGNITE-13495 > ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node > as > coordinator > > IGNITE-13479 > Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh > doesn't > start if JMX port was set > > IGNITE-11312 > JDBC: Thin driver reports incorrect property names > > IGNITE-13462 > .NET: Thin client Dispose hangs when continuous query is active on > .NET > Core 3.x > > IGNITE-13484 > C++ odbc-example losing some values if run with 1 additional node > > IGNITE-13477 > Fix NPE in SQL tracing implementation. > > IGNITE-13435 > Fixing some unrecorded issues command warm-up control.sh > > IGNITE-13403 > Update JDBC metadata to match actual capabilities > > IGNITE-13427 > The local metastorage system view fails if unmarshallable values > present > > IGNITE-13401 > Unsupported protocol version exception when getting cache > configuration > from Java thin client > > IGNITE-13388 > apache-ignite deb package depends on a non-existent package and can't > be > installed on Debian 10 > > IGNITE-13397 > NPE in logSupplierDone(UUID nodeId) > > IGNITE-13296 > .NET: TransactionImpl finalizer can crash the process > > IGNITE-13382 > DurableBackgroundTask can abandon incomplete task > > IGNITE-12509 > CACHE_REBALANCE_STOPPED event raises for wrong caches in case of > >>> specified > RebalanceDelay > > IGNITE-13072 > Synchronization problems when different classloaders are used for > deployment of same class > > IGNITE-13379 > Exception occur on SQL caches when client reconnect > > IGNITE-13363 > GridDhtCacheEntry::toString locks > > IGNITE-13373 > WAL segmentns do not released on releaseHistoryForPreloading() > > IGNITE-13540 >
Re: 2.9.1 release proposal
Hello, I suggest that the remaining document issue in version 2.9.0 can be solved in version 2.9.1, and it is not a good practice to postpone to version 2.10. 在 2020/10/27 上午2:00, Maxim Muzafarov 写道: Hello, +1 Should we start the discussion about the release leader and release dates? On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov wrote: +1 to start the 2.9.1 release process once as soon as 2.9 released. On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov wrote: Hello, Yaroslav. I support the idea. But, we should carefully work with the release scope. IGNITE-13477 - fix for a SQL tracing that will be available only in 2.10 IGNITE-13427 - fix for a new system view that exists in master only, we need to include IGNITE-13409 Other tickets should be checked, also. Is this a real fix of a released bug or we fix some issue we bring with the brand new contribution. I propose to include the following tickets, also: CMD tools improvements: IGNITE-13488 - Command to print metric value IGNITE-13426 - Command to print system view content IGNITE-13422 - Parameter to explicitly enable experimental commands IGNITE-13380 - Output IgniteSystemProperties via ignite.sh New system views: IGNITE-13409 Metastorage and DistributedMetastorage viewы. IGNITE-13408 BinaryMetadata view. 19 окт. 2020 г., в 18:20, Yaroslav Molochkov написал(а): Hello, Igniters! I've compiled a list of tickets that, i think, deserve to be released in a minor Ignite release (meaning in 2.9.1) after 2.9. Here they are: IGNITE-13569 disable archiving + walCompactionEnabled probably broke reading from wal on server restart IGNITE-13418 Deadlock on multiple cache delete IGNITE-13563 Deserializing IBinaryObject containing an IBinaryObject field fails IGNITE-13575 Invalid blocking section in GridNioWorker and GridNioClientWorker leads to false positive blocking thread detection IGNITE-13458 RebalancingPartitionsTotal metrics IGNITE-13536 .NET: Child processes become zombies when persistence is used with direct-io on Linux IGNITE-13500 Checkpoint read lock fail if it is taking under write lock during the stopping node IGNITE-13431 NPE during Cassandra Store initialization with PRIMITIVE strategy IGNITE-13417 Cache Interceptors deserialization on client nodes IGNITE-13495 ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as coordinator IGNITE-13479 Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh doesn't start if JMX port was set IGNITE-11312 JDBC: Thin driver reports incorrect property names IGNITE-13462 .NET: Thin client Dispose hangs when continuous query is active on .NET Core 3.x IGNITE-13484 C++ odbc-example losing some values if run with 1 additional node IGNITE-13477 Fix NPE in SQL tracing implementation. IGNITE-13435 Fixing some unrecorded issues command warm-up control.sh IGNITE-13403 Update JDBC metadata to match actual capabilities IGNITE-13427 The local metastorage system view fails if unmarshallable values present IGNITE-13401 Unsupported protocol version exception when getting cache configuration from Java thin client IGNITE-13388 apache-ignite deb package depends on a non-existent package and can't be installed on Debian 10 IGNITE-13397 NPE in logSupplierDone(UUID nodeId) IGNITE-13296 .NET: TransactionImpl finalizer can crash the process IGNITE-13382 DurableBackgroundTask can abandon incomplete task IGNITE-12509 CACHE_REBALANCE_STOPPED event raises for wrong caches in case of specified RebalanceDelay IGNITE-13072 Synchronization problems when different classloaders are used for deployment of same class IGNITE-13379 Exception occur on SQL caches when client reconnect IGNITE-13363 GridDhtCacheEntry::toString locks IGNITE-13373 WAL segmentns do not released on releaseHistoryForPreloading() IGNITE-13540 Exchange worker, waiting for new task from queue, considered as blocked. IGNITE-13491 Fix incorrect topology snapshot logger output about coordinator change. IGNITE-13439 Printing detailed classpath slowdowns node initialization WDYT?
Re: 2.9.1 release proposal
Hello, +1 Should we start the discussion about the release leader and release dates? On Tue, 20 Oct 2020 at 10:12, Anton Vinogradov wrote: > > +1 to start the 2.9.1 release process once as soon as 2.9 released. > > On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov wrote: > > > Hello, Yaroslav. > > > > I support the idea. > > But, we should carefully work with the release scope. > > > > IGNITE-13477 - fix for a SQL tracing that will be available only in 2.10 > > IGNITE-13427 - fix for a new system view that exists in master only, we > > need to include IGNITE-13409 > > > > Other tickets should be checked, also. > > Is this a real fix of a released bug or we fix some issue we bring with > > the brand new contribution. > > > > > > I propose to include the following tickets, also: > > > > CMD tools improvements: > > > > IGNITE-13488 - Command to print metric value > > IGNITE-13426 - Command to print system view content > > IGNITE-13422 - Parameter to explicitly enable experimental commands > > > > IGNITE-13380 - Output IgniteSystemProperties via ignite.sh > > > > New system views: > > > > IGNITE-13409 Metastorage and DistributedMetastorage viewы. > > IGNITE-13408 BinaryMetadata view. > > > > > > > 19 окт. 2020 г., в 18:20, Yaroslav Molochkov > > написал(а): > > > > > > Hello, Igniters! > > > > > > I've compiled a list of tickets that, i think, deserve to be released in > > a > > > minor Ignite release (meaning in 2.9.1) after 2.9. Here they are: > > > > > > IGNITE-13569 > > > disable archiving + walCompactionEnabled probably broke reading from wal > > on > > > server restart > > > > > > IGNITE-13418 > > > Deadlock on multiple cache delete > > > > > > IGNITE-13563 > > > Deserializing IBinaryObject containing an IBinaryObject field fails > > > > > > IGNITE-13575 > > > Invalid blocking section in GridNioWorker and GridNioClientWorker leads > > to > > > false positive blocking thread detection > > > > > > IGNITE-13458 > > > RebalancingPartitionsTotal metrics > > > > > > IGNITE-13536 > > > .NET: Child processes become zombies when persistence is used with > > > direct-io on Linux > > > > > > IGNITE-13500 > > > Checkpoint read lock fail if it is taking under write lock during the > > > stopping node > > > > > > IGNITE-13431 > > > NPE during Cassandra Store initialization with PRIMITIVE strategy > > > > > > IGNITE-13417 > > > Cache Interceptors deserialization on client nodes > > > > > > IGNITE-13495 > > > ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as > > > coordinator > > > > > > IGNITE-13479 > > > Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh doesn't > > > start if JMX port was set > > > > > > IGNITE-11312 > > > JDBC: Thin driver reports incorrect property names > > > > > > IGNITE-13462 > > > .NET: Thin client Dispose hangs when continuous query is active on .NET > > > Core 3.x > > > > > > IGNITE-13484 > > > C++ odbc-example losing some values if run with 1 additional node > > > > > > IGNITE-13477 > > > Fix NPE in SQL tracing implementation. > > > > > > IGNITE-13435 > > > Fixing some unrecorded issues command warm-up control.sh > > > > > > IGNITE-13403 > > > Update JDBC metadata to match actual capabilities > > > > > > IGNITE-13427 > > > The local metastorage system view fails if unmarshallable values present > > > > > > IGNITE-13401 > > > Unsupported protocol version exception when getting cache configuration > > > from Java thin client > > > > > > IGNITE-13388 > > > apache-ignite deb package depends on a non-existent package and can't be > > > installed on Debian 10 > > > > > > IGNITE-13397 > > > NPE in logSupplierDone(UUID nodeId) > > > > > > IGNITE-13296 > > > .NET: TransactionImpl finalizer can crash the process > > > > > > IGNITE-13382 > > > DurableBackgroundTask can abandon incomplete task > > > > > > IGNITE-12509 > > > CACHE_REBALANCE_STOPPED event raises for wrong caches in case of > > specified > > > RebalanceDelay > > > > > > IGNITE-13072 > > > Synchronization problems when different classloaders are used for > > > deployment of same class > > > > > > IGNITE-13379 > > > Exception occur on SQL caches when client reconnect > > > > > > IGNITE-13363 > > > GridDhtCacheEntry::toString locks > > > > > > IGNITE-13373 > > > WAL segmentns do not released on releaseHistoryForPreloading() > > > > > > IGNITE-13540 > > > Exchange worker, waiting for new task from queue, considered as blocked. > > > > > > IGNITE-13491 > > > Fix incorrect topology snapshot logger output about coordinator change. > > > > > > IGNITE-13439 > > > Printing detailed classpath slowdowns node initialization > > > > > > WDYT? > > > >
Re: 2.9.1 release proposal
+1 to start the 2.9.1 release process once as soon as 2.9 released. On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov wrote: > Hello, Yaroslav. > > I support the idea. > But, we should carefully work with the release scope. > > IGNITE-13477 - fix for a SQL tracing that will be available only in 2.10 > IGNITE-13427 - fix for a new system view that exists in master only, we > need to include IGNITE-13409 > > Other tickets should be checked, also. > Is this a real fix of a released bug or we fix some issue we bring with > the brand new contribution. > > > I propose to include the following tickets, also: > > CMD tools improvements: > > IGNITE-13488 - Command to print metric value > IGNITE-13426 - Command to print system view content > IGNITE-13422 - Parameter to explicitly enable experimental commands > > IGNITE-13380 - Output IgniteSystemProperties via ignite.sh > > New system views: > > IGNITE-13409 Metastorage and DistributedMetastorage viewы. > IGNITE-13408 BinaryMetadata view. > > > > 19 окт. 2020 г., в 18:20, Yaroslav Molochkov > написал(а): > > > > Hello, Igniters! > > > > I've compiled a list of tickets that, i think, deserve to be released in > a > > minor Ignite release (meaning in 2.9.1) after 2.9. Here they are: > > > > IGNITE-13569 > > disable archiving + walCompactionEnabled probably broke reading from wal > on > > server restart > > > > IGNITE-13418 > > Deadlock on multiple cache delete > > > > IGNITE-13563 > > Deserializing IBinaryObject containing an IBinaryObject field fails > > > > IGNITE-13575 > > Invalid blocking section in GridNioWorker and GridNioClientWorker leads > to > > false positive blocking thread detection > > > > IGNITE-13458 > > RebalancingPartitionsTotal metrics > > > > IGNITE-13536 > > .NET: Child processes become zombies when persistence is used with > > direct-io on Linux > > > > IGNITE-13500 > > Checkpoint read lock fail if it is taking under write lock during the > > stopping node > > > > IGNITE-13431 > > NPE during Cassandra Store initialization with PRIMITIVE strategy > > > > IGNITE-13417 > > Cache Interceptors deserialization on client nodes > > > > IGNITE-13495 > > ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as > > coordinator > > > > IGNITE-13479 > > Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh doesn't > > start if JMX port was set > > > > IGNITE-11312 > > JDBC: Thin driver reports incorrect property names > > > > IGNITE-13462 > > .NET: Thin client Dispose hangs when continuous query is active on .NET > > Core 3.x > > > > IGNITE-13484 > > C++ odbc-example losing some values if run with 1 additional node > > > > IGNITE-13477 > > Fix NPE in SQL tracing implementation. > > > > IGNITE-13435 > > Fixing some unrecorded issues command warm-up control.sh > > > > IGNITE-13403 > > Update JDBC metadata to match actual capabilities > > > > IGNITE-13427 > > The local metastorage system view fails if unmarshallable values present > > > > IGNITE-13401 > > Unsupported protocol version exception when getting cache configuration > > from Java thin client > > > > IGNITE-13388 > > apache-ignite deb package depends on a non-existent package and can't be > > installed on Debian 10 > > > > IGNITE-13397 > > NPE in logSupplierDone(UUID nodeId) > > > > IGNITE-13296 > > .NET: TransactionImpl finalizer can crash the process > > > > IGNITE-13382 > > DurableBackgroundTask can abandon incomplete task > > > > IGNITE-12509 > > CACHE_REBALANCE_STOPPED event raises for wrong caches in case of > specified > > RebalanceDelay > > > > IGNITE-13072 > > Synchronization problems when different classloaders are used for > > deployment of same class > > > > IGNITE-13379 > > Exception occur on SQL caches when client reconnect > > > > IGNITE-13363 > > GridDhtCacheEntry::toString locks > > > > IGNITE-13373 > > WAL segmentns do not released on releaseHistoryForPreloading() > > > > IGNITE-13540 > > Exchange worker, waiting for new task from queue, considered as blocked. > > > > IGNITE-13491 > > Fix incorrect topology snapshot logger output about coordinator change. > > > > IGNITE-13439 > > Printing detailed classpath slowdowns node initialization > > > > WDYT? > >
Re: 2.9.1 release proposal
Hello, Yaroslav. I support the idea. But, we should carefully work with the release scope. IGNITE-13477 - fix for a SQL tracing that will be available only in 2.10 IGNITE-13427 - fix for a new system view that exists in master only, we need to include IGNITE-13409 Other tickets should be checked, also. Is this a real fix of a released bug or we fix some issue we bring with the brand new contribution. I propose to include the following tickets, also: CMD tools improvements: IGNITE-13488 - Command to print metric value IGNITE-13426 - Command to print system view content IGNITE-13422 - Parameter to explicitly enable experimental commands IGNITE-13380 - Output IgniteSystemProperties via ignite.sh New system views: IGNITE-13409 Metastorage and DistributedMetastorage viewы. IGNITE-13408 BinaryMetadata view. > 19 окт. 2020 г., в 18:20, Yaroslav Molochkov > написал(а): > > Hello, Igniters! > > I've compiled a list of tickets that, i think, deserve to be released in a > minor Ignite release (meaning in 2.9.1) after 2.9. Here they are: > > IGNITE-13569 > disable archiving + walCompactionEnabled probably broke reading from wal on > server restart > > IGNITE-13418 > Deadlock on multiple cache delete > > IGNITE-13563 > Deserializing IBinaryObject containing an IBinaryObject field fails > > IGNITE-13575 > Invalid blocking section in GridNioWorker and GridNioClientWorker leads to > false positive blocking thread detection > > IGNITE-13458 > RebalancingPartitionsTotal metrics > > IGNITE-13536 > .NET: Child processes become zombies when persistence is used with > direct-io on Linux > > IGNITE-13500 > Checkpoint read lock fail if it is taking under write lock during the > stopping node > > IGNITE-13431 > NPE during Cassandra Store initialization with PRIMITIVE strategy > > IGNITE-13417 > Cache Interceptors deserialization on client nodes > > IGNITE-13495 > ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as > coordinator > > IGNITE-13479 > Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh doesn't > start if JMX port was set > > IGNITE-11312 > JDBC: Thin driver reports incorrect property names > > IGNITE-13462 > .NET: Thin client Dispose hangs when continuous query is active on .NET > Core 3.x > > IGNITE-13484 > C++ odbc-example losing some values if run with 1 additional node > > IGNITE-13477 > Fix NPE in SQL tracing implementation. > > IGNITE-13435 > Fixing some unrecorded issues command warm-up control.sh > > IGNITE-13403 > Update JDBC metadata to match actual capabilities > > IGNITE-13427 > The local metastorage system view fails if unmarshallable values present > > IGNITE-13401 > Unsupported protocol version exception when getting cache configuration > from Java thin client > > IGNITE-13388 > apache-ignite deb package depends on a non-existent package and can't be > installed on Debian 10 > > IGNITE-13397 > NPE in logSupplierDone(UUID nodeId) > > IGNITE-13296 > .NET: TransactionImpl finalizer can crash the process > > IGNITE-13382 > DurableBackgroundTask can abandon incomplete task > > IGNITE-12509 > CACHE_REBALANCE_STOPPED event raises for wrong caches in case of specified > RebalanceDelay > > IGNITE-13072 > Synchronization problems when different classloaders are used for > deployment of same class > > IGNITE-13379 > Exception occur on SQL caches when client reconnect > > IGNITE-13363 > GridDhtCacheEntry::toString locks > > IGNITE-13373 > WAL segmentns do not released on releaseHistoryForPreloading() > > IGNITE-13540 > Exchange worker, waiting for new task from queue, considered as blocked. > > IGNITE-13491 > Fix incorrect topology snapshot logger output about coordinator change. > > IGNITE-13439 > Printing detailed classpath slowdowns node initialization > > WDYT?
2.9.1 release proposal
Hello, Igniters! I've compiled a list of tickets that, i think, deserve to be released in a minor Ignite release (meaning in 2.9.1) after 2.9. Here they are: IGNITE-13569 disable archiving + walCompactionEnabled probably broke reading from wal on server restart IGNITE-13418 Deadlock on multiple cache delete IGNITE-13563 Deserializing IBinaryObject containing an IBinaryObject field fails IGNITE-13575 Invalid blocking section in GridNioWorker and GridNioClientWorker leads to false positive blocking thread detection IGNITE-13458 RebalancingPartitionsTotal metrics IGNITE-13536 .NET: Child processes become zombies when persistence is used with direct-io on Linux IGNITE-13500 Checkpoint read lock fail if it is taking under write lock during the stopping node IGNITE-13431 NPE during Cassandra Store initialization with PRIMITIVE strategy IGNITE-13417 Cache Interceptors deserialization on client nodes IGNITE-13495 ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as coordinator IGNITE-13479 Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh doesn't start if JMX port was set IGNITE-11312 JDBC: Thin driver reports incorrect property names IGNITE-13462 .NET: Thin client Dispose hangs when continuous query is active on .NET Core 3.x IGNITE-13484 C++ odbc-example losing some values if run with 1 additional node IGNITE-13477 Fix NPE in SQL tracing implementation. IGNITE-13435 Fixing some unrecorded issues command warm-up control.sh IGNITE-13403 Update JDBC metadata to match actual capabilities IGNITE-13427 The local metastorage system view fails if unmarshallable values present IGNITE-13401 Unsupported protocol version exception when getting cache configuration from Java thin client IGNITE-13388 apache-ignite deb package depends on a non-existent package and can't be installed on Debian 10 IGNITE-13397 NPE in logSupplierDone(UUID nodeId) IGNITE-13296 .NET: TransactionImpl finalizer can crash the process IGNITE-13382 DurableBackgroundTask can abandon incomplete task IGNITE-12509 CACHE_REBALANCE_STOPPED event raises for wrong caches in case of specified RebalanceDelay IGNITE-13072 Synchronization problems when different classloaders are used for deployment of same class IGNITE-13379 Exception occur on SQL caches when client reconnect IGNITE-13363 GridDhtCacheEntry::toString locks IGNITE-13373 WAL segmentns do not released on releaseHistoryForPreloading() IGNITE-13540 Exchange worker, waiting for new task from queue, considered as blocked. IGNITE-13491 Fix incorrect topology snapshot logger output about coordinator change. IGNITE-13439 Printing detailed classpath slowdowns node initialization WDYT?
Re: Proposal of new event QUERY_EXECUTION_EVENT
Юрий, can you take a look? JIRA - https://issues.apache.org/jira/browse/IGNITE-13450 PR - https://github.com/apache/ignite/pull/8252 вт, 15 сент. 2020 г. в 08:59, Dmitrii Ryabov : > > Ok, I created a ticket [1]. > > [1] https://issues.apache.org/jira/browse/IGNITE-13450 > > пн, 14 сент. 2020 г. в 14:59, Юрий : > > > > Dmitrii, seems you are right and we can go with new separate event > > > > пн, 7 сент. 2020 г. в 23:53, Dmitrii Ryabov : > > > > > Any objections to create a separate event, which will be fired before > > > executing a query? > > > > > > ср, 2 сент. 2020 г. в 22:33, Dmitrii Ryabov : > > > > > > > > I agree with Max, we need to add a separate event for starting query > > > > execution, and EVT_CACHE_QUERY_EXECUTED shouldn't be deprecated, > > > > because it is another case - it is fired when cache query was > > > > successfully finished. > > > > > > > > > Would the event notification be synchronous? In which thread? > > > > As Max said, synchronicity depends on implementation. As I see, we > > > > don't use a separate thread for any record calls. > > > > > > > > > What happens in case the event listener fails? > > > > Exceptions are logged by `U.error(...)` call. Errors are thrown out. > > > > > > > > > Should we discuss this within this topic? > > > > I suggest to separate adding a new event and configuring existing > > > > events. > > > > > > > > пн, 20 июл. 2020 г. в 14:37, Max Timonin : > > > > > > > > > > Looks like EVT_CACHE_QUERY_EXECUTED just works for different use > > > > > cases: > > > > > 1. it relates to a specific cache (Event for SQL queries looks > > > different as > > > > > it could contain multiple caches or none of them); > > > > > 2. Also the EVT_CACHE_QUERY_EXECUTED event fires multiple times for > > > > > distributed queries, see GridMapQueryExecutor class (For SQL query > > > > > it's > > > > > required to fire once independently on how many nodes are affected). > > > > > > > > > > So there are different patterns for events. I think > > > > > EVT_CACHE_QUERY_EXECUTED should not be deprecated or changed. > > > > > > > > > > > What happens in case the event listener fails? > > > > > > Would the event notification be synchronous? > > > > > It depends on how other events are implemented. As I see for the > > > > > EVT_CACHE_QUERY_EXECUTED event - it's synchronous, and listener errors > > > > > aren't handled. > > > > > > > > > > I think these questions are related to GridEventStorageManager as it > > > just > > > > > provides an API for recording events. Internal implementations (sync > > > > > / async, error handling) is not related to an event, is it? > > > > > > > > > > > I have some doubts about provide text of a query even with > > > > > hidden arguments, probably it should be configured due to it could > > > > > lead > > > > > to security leak > > > > > Currently event EVT_CACHE_QUERY_EXECUTED provides a sql clause without > > > > > limitations. If we're going to provide some restrictions it will > > > require > > > > > additional investigation. I see at least 2 configurations here: > > > > > 1. Ignite can be configured to hide clase, params only or nothing for > > > all > > > > > listeners; > > > > > 2. Only authorized listeners can subscribe to the event. > > > > > > > > > > Should we discuss this within this topic? > > > > > > > > > > On Mon, Jul 20, 2020 at 1:55 PM Юрий > > > wrote: > > > > > > > > > > > In my opinion existing events EVT_CACHE_QUERY_EXECUTION_STARTED > > > should be > > > > > > deprecated and added two new for start and for end of queries which > > > should > > > > > > cover all SQL query types. > > > > > > I have some doubts about provide text of a query even with hidden > > > > > > arguments, probably it should be configured due to it could lead to > > > > > > security leak > > > > > > > > > > > > пн, 20 июл. 2020 г. в 12:49, Stanislav Lukyanov < > > > stanlukya...@gmail.com>: > > > > > > > > > > > > > Maksim, > > > > > > > > > > > > > > Can we change the EVT_CACHE_QUERY_EXECUTED to fire earlier? Or > > > should > > > > > > > there be an EVT_CACHE_QUERY_EXECUTION_STARTED for the query start, > > > while > > > > > > > the old event would continue to work for query finish? > > > > > > > I think the new event needs to either reuse the old one, or be its > > > mirror > > > > > > > for the query start. It also means that we probably should resolve > > > the > > > > > > > issues you've listed. > > > > > > > > > > > > > > Would the event notification be synchronous? In which thread? > > > > > > Asynchronous > > > > > > > is generally preferred - would it work? > > > > > > > > > > > > > > What happens in case the event listener fails? > > > > > > > > > > > > > > Thanks, > > > > > > > Stan > > > > > > > > > > > > > > > On 16 Jul 2020, at 18:49, Denis Magda wrote: > > > > > > > > > > > > > > > > Taras, Yury, Ivan, > > > > > > > > > > > > > > > > Could you please join this thread and share your thoughts? Do we > > > > > > already > > > > > > > >
Re: Proposal of new event QUERY_EXECUTION_EVENT
Ok, I created a ticket [1]. [1] https://issues.apache.org/jira/browse/IGNITE-13450 пн, 14 сент. 2020 г. в 14:59, Юрий : > > Dmitrii, seems you are right and we can go with new separate event > > пн, 7 сент. 2020 г. в 23:53, Dmitrii Ryabov : > > > Any objections to create a separate event, which will be fired before > > executing a query? > > > > ср, 2 сент. 2020 г. в 22:33, Dmitrii Ryabov : > > > > > > I agree with Max, we need to add a separate event for starting query > > > execution, and EVT_CACHE_QUERY_EXECUTED shouldn't be deprecated, > > > because it is another case - it is fired when cache query was > > > successfully finished. > > > > > > > Would the event notification be synchronous? In which thread? > > > As Max said, synchronicity depends on implementation. As I see, we > > > don't use a separate thread for any record calls. > > > > > > > What happens in case the event listener fails? > > > Exceptions are logged by `U.error(...)` call. Errors are thrown out. > > > > > > > Should we discuss this within this topic? > > > I suggest to separate adding a new event and configuring existing events. > > > > > > пн, 20 июл. 2020 г. в 14:37, Max Timonin : > > > > > > > > Looks like EVT_CACHE_QUERY_EXECUTED just works for different use cases: > > > > 1. it relates to a specific cache (Event for SQL queries looks > > different as > > > > it could contain multiple caches or none of them); > > > > 2. Also the EVT_CACHE_QUERY_EXECUTED event fires multiple times for > > > > distributed queries, see GridMapQueryExecutor class (For SQL query it's > > > > required to fire once independently on how many nodes are affected). > > > > > > > > So there are different patterns for events. I think > > > > EVT_CACHE_QUERY_EXECUTED should not be deprecated or changed. > > > > > > > > > What happens in case the event listener fails? > > > > > Would the event notification be synchronous? > > > > It depends on how other events are implemented. As I see for the > > > > EVT_CACHE_QUERY_EXECUTED event - it's synchronous, and listener errors > > > > aren't handled. > > > > > > > > I think these questions are related to GridEventStorageManager as it > > just > > > > provides an API for recording events. Internal implementations (sync > > > > / async, error handling) is not related to an event, is it? > > > > > > > > > I have some doubts about provide text of a query even with > > > > hidden arguments, probably it should be configured due to it could lead > > > > to security leak > > > > Currently event EVT_CACHE_QUERY_EXECUTED provides a sql clause without > > > > limitations. If we're going to provide some restrictions it will > > require > > > > additional investigation. I see at least 2 configurations here: > > > > 1. Ignite can be configured to hide clase, params only or nothing for > > all > > > > listeners; > > > > 2. Only authorized listeners can subscribe to the event. > > > > > > > > Should we discuss this within this topic? > > > > > > > > On Mon, Jul 20, 2020 at 1:55 PM Юрий > > wrote: > > > > > > > > > In my opinion existing events EVT_CACHE_QUERY_EXECUTION_STARTED > > should be > > > > > deprecated and added two new for start and for end of queries which > > should > > > > > cover all SQL query types. > > > > > I have some doubts about provide text of a query even with hidden > > > > > arguments, probably it should be configured due to it could lead to > > > > > security leak > > > > > > > > > > пн, 20 июл. 2020 г. в 12:49, Stanislav Lukyanov < > > stanlukya...@gmail.com>: > > > > > > > > > > > Maksim, > > > > > > > > > > > > Can we change the EVT_CACHE_QUERY_EXECUTED to fire earlier? Or > > should > > > > > > there be an EVT_CACHE_QUERY_EXECUTION_STARTED for the query start, > > while > > > > > > the old event would continue to work for query finish? > > > > > > I think the new event needs to either reuse the old one, or be its > > mirror > > > > > > for the query start. It also means that we probably should resolve > > the > > > > > > issues you've listed. > > > > > > > > > > > > Would the event notification be synchronous? In which thread? > > > > > Asynchronous > > > > > > is generally preferred - would it work? > > > > > > > > > > > > What happens in case the event listener fails? > > > > > > > > > > > > Thanks, > > > > > > Stan > > > > > > > > > > > > > On 16 Jul 2020, at 18:49, Denis Magda wrote: > > > > > > > > > > > > > > Taras, Yury, Ivan, > > > > > > > > > > > > > > Could you please join this thread and share your thoughts? Do we > > > > > already > > > > > > > have any plans on tracking of the DDL and DML queries? > > > > > > > > > > > > > > - > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 15, 2020 at 12:09 AM Max Timonin < > > timonin.ma...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > >> Hi Denis, thanks for the answer! > > > > > > >> > > > > > > >> We already checked EVT_CACHE_QUERY_EXECUTED and found that it > > works > > > > > > only in > > > > > > >> cases:
Re: Proposal of new event QUERY_EXECUTION_EVENT
Dmitrii, seems you are right and we can go with new separate event пн, 7 сент. 2020 г. в 23:53, Dmitrii Ryabov : > Any objections to create a separate event, which will be fired before > executing a query? > > ср, 2 сент. 2020 г. в 22:33, Dmitrii Ryabov : > > > > I agree with Max, we need to add a separate event for starting query > > execution, and EVT_CACHE_QUERY_EXECUTED shouldn't be deprecated, > > because it is another case - it is fired when cache query was > > successfully finished. > > > > > Would the event notification be synchronous? In which thread? > > As Max said, synchronicity depends on implementation. As I see, we > > don't use a separate thread for any record calls. > > > > > What happens in case the event listener fails? > > Exceptions are logged by `U.error(...)` call. Errors are thrown out. > > > > > Should we discuss this within this topic? > > I suggest to separate adding a new event and configuring existing events. > > > > пн, 20 июл. 2020 г. в 14:37, Max Timonin : > > > > > > Looks like EVT_CACHE_QUERY_EXECUTED just works for different use cases: > > > 1. it relates to a specific cache (Event for SQL queries looks > different as > > > it could contain multiple caches or none of them); > > > 2. Also the EVT_CACHE_QUERY_EXECUTED event fires multiple times for > > > distributed queries, see GridMapQueryExecutor class (For SQL query it's > > > required to fire once independently on how many nodes are affected). > > > > > > So there are different patterns for events. I think > > > EVT_CACHE_QUERY_EXECUTED should not be deprecated or changed. > > > > > > > What happens in case the event listener fails? > > > > Would the event notification be synchronous? > > > It depends on how other events are implemented. As I see for the > > > EVT_CACHE_QUERY_EXECUTED event - it's synchronous, and listener errors > > > aren't handled. > > > > > > I think these questions are related to GridEventStorageManager as it > just > > > provides an API for recording events. Internal implementations (sync > > > / async, error handling) is not related to an event, is it? > > > > > > > I have some doubts about provide text of a query even with > > > hidden arguments, probably it should be configured due to it could lead > > > to security leak > > > Currently event EVT_CACHE_QUERY_EXECUTED provides a sql clause without > > > limitations. If we're going to provide some restrictions it will > require > > > additional investigation. I see at least 2 configurations here: > > > 1. Ignite can be configured to hide clase, params only or nothing for > all > > > listeners; > > > 2. Only authorized listeners can subscribe to the event. > > > > > > Should we discuss this within this topic? > > > > > > On Mon, Jul 20, 2020 at 1:55 PM Юрий > wrote: > > > > > > > In my opinion existing events EVT_CACHE_QUERY_EXECUTION_STARTED > should be > > > > deprecated and added two new for start and for end of queries which > should > > > > cover all SQL query types. > > > > I have some doubts about provide text of a query even with hidden > > > > arguments, probably it should be configured due to it could lead to > > > > security leak > > > > > > > > пн, 20 июл. 2020 г. в 12:49, Stanislav Lukyanov < > stanlukya...@gmail.com>: > > > > > > > > > Maksim, > > > > > > > > > > Can we change the EVT_CACHE_QUERY_EXECUTED to fire earlier? Or > should > > > > > there be an EVT_CACHE_QUERY_EXECUTION_STARTED for the query start, > while > > > > > the old event would continue to work for query finish? > > > > > I think the new event needs to either reuse the old one, or be its > mirror > > > > > for the query start. It also means that we probably should resolve > the > > > > > issues you've listed. > > > > > > > > > > Would the event notification be synchronous? In which thread? > > > > Asynchronous > > > > > is generally preferred - would it work? > > > > > > > > > > What happens in case the event listener fails? > > > > > > > > > > Thanks, > > > > > Stan > > > > > > > > > > > On 16 Jul 2020, at 18:49, Denis Magda wrote: > > > > > > > > > > > > Taras, Yury, Ivan, > > > > > > > > > > > > Could you please join this thread and share your thoughts? Do we > > > > already > > > > > > have any plans on tracking of the DDL and DML queries? > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Wed, Jul 15, 2020 at 12:09 AM Max Timonin < > timonin.ma...@gmail.com> > > > > > > wrote: > > > > > > > > > > > >> Hi Denis, thanks for the answer! > > > > > >> > > > > > >> We already checked EVT_CACHE_QUERY_EXECUTED and found that it > works > > > > > only in > > > > > >> cases: > > > > > >> 1. Scan queries and Select queries (common pattern is access to > cache > > > > > >> data); > > > > > >> 2. This event triggers only if query execution succeeds, in > case of > > > > > failure > > > > > >> while execution this event won't fire. > > > > > >> > > > > > >> Our additional requirements are to protocol queries: > > > > > >> 1. that aren't
Re: Proposal of new event QUERY_EXECUTION_EVENT
Ignite SQL experts, could you please step in? - Denis On Mon, Sep 7, 2020 at 1:53 PM Dmitrii Ryabov wrote: > Any objections to create a separate event, which will be fired before > executing a query? > > ср, 2 сент. 2020 г. в 22:33, Dmitrii Ryabov : > > > > I agree with Max, we need to add a separate event for starting query > > execution, and EVT_CACHE_QUERY_EXECUTED shouldn't be deprecated, > > because it is another case - it is fired when cache query was > > successfully finished. > > > > > Would the event notification be synchronous? In which thread? > > As Max said, synchronicity depends on implementation. As I see, we > > don't use a separate thread for any record calls. > > > > > What happens in case the event listener fails? > > Exceptions are logged by `U.error(...)` call. Errors are thrown out. > > > > > Should we discuss this within this topic? > > I suggest to separate adding a new event and configuring existing events. > > > > пн, 20 июл. 2020 г. в 14:37, Max Timonin : > > > > > > Looks like EVT_CACHE_QUERY_EXECUTED just works for different use cases: > > > 1. it relates to a specific cache (Event for SQL queries looks > different as > > > it could contain multiple caches or none of them); > > > 2. Also the EVT_CACHE_QUERY_EXECUTED event fires multiple times for > > > distributed queries, see GridMapQueryExecutor class (For SQL query it's > > > required to fire once independently on how many nodes are affected). > > > > > > So there are different patterns for events. I think > > > EVT_CACHE_QUERY_EXECUTED should not be deprecated or changed. > > > > > > > What happens in case the event listener fails? > > > > Would the event notification be synchronous? > > > It depends on how other events are implemented. As I see for the > > > EVT_CACHE_QUERY_EXECUTED event - it's synchronous, and listener errors > > > aren't handled. > > > > > > I think these questions are related to GridEventStorageManager as it > just > > > provides an API for recording events. Internal implementations (sync > > > / async, error handling) is not related to an event, is it? > > > > > > > I have some doubts about provide text of a query even with > > > hidden arguments, probably it should be configured due to it could lead > > > to security leak > > > Currently event EVT_CACHE_QUERY_EXECUTED provides a sql clause without > > > limitations. If we're going to provide some restrictions it will > require > > > additional investigation. I see at least 2 configurations here: > > > 1. Ignite can be configured to hide clase, params only or nothing for > all > > > listeners; > > > 2. Only authorized listeners can subscribe to the event. > > > > > > Should we discuss this within this topic? > > > > > > On Mon, Jul 20, 2020 at 1:55 PM Юрий > wrote: > > > > > > > In my opinion existing events EVT_CACHE_QUERY_EXECUTION_STARTED > should be > > > > deprecated and added two new for start and for end of queries which > should > > > > cover all SQL query types. > > > > I have some doubts about provide text of a query even with hidden > > > > arguments, probably it should be configured due to it could lead to > > > > security leak > > > > > > > > пн, 20 июл. 2020 г. в 12:49, Stanislav Lukyanov < > stanlukya...@gmail.com>: > > > > > > > > > Maksim, > > > > > > > > > > Can we change the EVT_CACHE_QUERY_EXECUTED to fire earlier? Or > should > > > > > there be an EVT_CACHE_QUERY_EXECUTION_STARTED for the query start, > while > > > > > the old event would continue to work for query finish? > > > > > I think the new event needs to either reuse the old one, or be its > mirror > > > > > for the query start. It also means that we probably should resolve > the > > > > > issues you've listed. > > > > > > > > > > Would the event notification be synchronous? In which thread? > > > > Asynchronous > > > > > is generally preferred - would it work? > > > > > > > > > > What happens in case the event listener fails? > > > > > > > > > > Thanks, > > > > > Stan > > > > > > > > > > > On 16 Jul 2020, at 18:49, Denis Magda wrote: > > > > > > > > > > > > Taras, Yury, Ivan, > > > > > > > > > > > > Could you please join this thread and share your thoughts? Do we > > > > already > > > > > > have any plans on tracking of the DDL and DML queries? > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Wed, Jul 15, 2020 at 12:09 AM Max Timonin < > timonin.ma...@gmail.com> > > > > > > wrote: > > > > > > > > > > > >> Hi Denis, thanks for the answer! > > > > > >> > > > > > >> We already checked EVT_CACHE_QUERY_EXECUTED and found that it > works > > > > > only in > > > > > >> cases: > > > > > >> 1. Scan queries and Select queries (common pattern is access to > cache > > > > > >> data); > > > > > >> 2. This event triggers only if query execution succeeds, in > case of > > > > > failure > > > > > >> while execution this event won't fire. > > > > > >> > > > > > >> Our additional requirements are to protocol queries: > > > > > >> 1. that aren't
Re: Proposal of new event QUERY_EXECUTION_EVENT
Any objections to create a separate event, which will be fired before executing a query? ср, 2 сент. 2020 г. в 22:33, Dmitrii Ryabov : > > I agree with Max, we need to add a separate event for starting query > execution, and EVT_CACHE_QUERY_EXECUTED shouldn't be deprecated, > because it is another case - it is fired when cache query was > successfully finished. > > > Would the event notification be synchronous? In which thread? > As Max said, synchronicity depends on implementation. As I see, we > don't use a separate thread for any record calls. > > > What happens in case the event listener fails? > Exceptions are logged by `U.error(...)` call. Errors are thrown out. > > > Should we discuss this within this topic? > I suggest to separate adding a new event and configuring existing events. > > пн, 20 июл. 2020 г. в 14:37, Max Timonin : > > > > Looks like EVT_CACHE_QUERY_EXECUTED just works for different use cases: > > 1. it relates to a specific cache (Event for SQL queries looks different as > > it could contain multiple caches or none of them); > > 2. Also the EVT_CACHE_QUERY_EXECUTED event fires multiple times for > > distributed queries, see GridMapQueryExecutor class (For SQL query it's > > required to fire once independently on how many nodes are affected). > > > > So there are different patterns for events. I think > > EVT_CACHE_QUERY_EXECUTED should not be deprecated or changed. > > > > > What happens in case the event listener fails? > > > Would the event notification be synchronous? > > It depends on how other events are implemented. As I see for the > > EVT_CACHE_QUERY_EXECUTED event - it's synchronous, and listener errors > > aren't handled. > > > > I think these questions are related to GridEventStorageManager as it just > > provides an API for recording events. Internal implementations (sync > > / async, error handling) is not related to an event, is it? > > > > > I have some doubts about provide text of a query even with > > hidden arguments, probably it should be configured due to it could lead > > to security leak > > Currently event EVT_CACHE_QUERY_EXECUTED provides a sql clause without > > limitations. If we're going to provide some restrictions it will require > > additional investigation. I see at least 2 configurations here: > > 1. Ignite can be configured to hide clase, params only or nothing for all > > listeners; > > 2. Only authorized listeners can subscribe to the event. > > > > Should we discuss this within this topic? > > > > On Mon, Jul 20, 2020 at 1:55 PM Юрий wrote: > > > > > In my opinion existing events EVT_CACHE_QUERY_EXECUTION_STARTED should be > > > deprecated and added two new for start and for end of queries which should > > > cover all SQL query types. > > > I have some doubts about provide text of a query even with hidden > > > arguments, probably it should be configured due to it could lead to > > > security leak > > > > > > пн, 20 июл. 2020 г. в 12:49, Stanislav Lukyanov : > > > > > > > Maksim, > > > > > > > > Can we change the EVT_CACHE_QUERY_EXECUTED to fire earlier? Or should > > > > there be an EVT_CACHE_QUERY_EXECUTION_STARTED for the query start, while > > > > the old event would continue to work for query finish? > > > > I think the new event needs to either reuse the old one, or be its > > > > mirror > > > > for the query start. It also means that we probably should resolve the > > > > issues you've listed. > > > > > > > > Would the event notification be synchronous? In which thread? > > > Asynchronous > > > > is generally preferred - would it work? > > > > > > > > What happens in case the event listener fails? > > > > > > > > Thanks, > > > > Stan > > > > > > > > > On 16 Jul 2020, at 18:49, Denis Magda wrote: > > > > > > > > > > Taras, Yury, Ivan, > > > > > > > > > > Could you please join this thread and share your thoughts? Do we > > > already > > > > > have any plans on tracking of the DDL and DML queries? > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Wed, Jul 15, 2020 at 12:09 AM Max Timonin > > > > > wrote: > > > > > > > > > >> Hi Denis, thanks for the answer! > > > > >> > > > > >> We already checked EVT_CACHE_QUERY_EXECUTED and found that it works > > > > only in > > > > >> cases: > > > > >> 1. Scan queries and Select queries (common pattern is access to cache > > > > >> data); > > > > >> 2. This event triggers only if query execution succeeds, in case of > > > > failure > > > > >> while execution this event won't fire. > > > > >> > > > > >> Our additional requirements are to protocol queries: > > > > >> 1. that aren't cache related (for example, alter user); > > > > >> 2. that relate to multiple caches (while EVT_CACHE_QUERY_EXECUTED > > > > >> have > > > > >> field cacheName related to specific cache); > > > > >> 3. we need to protocol also DDL and DML queries. > > > > >> > > > > >> Regards, > > > > >> Maksim > > > > >> > > > > >> On Tue, Jul 14, 2020 at 10:20 PM Denis Magda > > > wrote: > > > > >> > > > > >>> Hi
Re: Proposal of new event QUERY_EXECUTION_EVENT
I agree with Max, we need to add a separate event for starting query execution, and EVT_CACHE_QUERY_EXECUTED shouldn't be deprecated, because it is another case - it is fired when cache query was successfully finished. > Would the event notification be synchronous? In which thread? As Max said, synchronicity depends on implementation. As I see, we don't use a separate thread for any record calls. > What happens in case the event listener fails? Exceptions are logged by `U.error(...)` call. Errors are thrown out. > Should we discuss this within this topic? I suggest to separate adding a new event and configuring existing events. пн, 20 июл. 2020 г. в 14:37, Max Timonin : > > Looks like EVT_CACHE_QUERY_EXECUTED just works for different use cases: > 1. it relates to a specific cache (Event for SQL queries looks different as > it could contain multiple caches or none of them); > 2. Also the EVT_CACHE_QUERY_EXECUTED event fires multiple times for > distributed queries, see GridMapQueryExecutor class (For SQL query it's > required to fire once independently on how many nodes are affected). > > So there are different patterns for events. I think > EVT_CACHE_QUERY_EXECUTED should not be deprecated or changed. > > > What happens in case the event listener fails? > > Would the event notification be synchronous? > It depends on how other events are implemented. As I see for the > EVT_CACHE_QUERY_EXECUTED event - it's synchronous, and listener errors > aren't handled. > > I think these questions are related to GridEventStorageManager as it just > provides an API for recording events. Internal implementations (sync > / async, error handling) is not related to an event, is it? > > > I have some doubts about provide text of a query even with > hidden arguments, probably it should be configured due to it could lead > to security leak > Currently event EVT_CACHE_QUERY_EXECUTED provides a sql clause without > limitations. If we're going to provide some restrictions it will require > additional investigation. I see at least 2 configurations here: > 1. Ignite can be configured to hide clase, params only or nothing for all > listeners; > 2. Only authorized listeners can subscribe to the event. > > Should we discuss this within this topic? > > On Mon, Jul 20, 2020 at 1:55 PM Юрий wrote: > > > In my opinion existing events EVT_CACHE_QUERY_EXECUTION_STARTED should be > > deprecated and added two new for start and for end of queries which should > > cover all SQL query types. > > I have some doubts about provide text of a query even with hidden > > arguments, probably it should be configured due to it could lead to > > security leak > > > > пн, 20 июл. 2020 г. в 12:49, Stanislav Lukyanov : > > > > > Maksim, > > > > > > Can we change the EVT_CACHE_QUERY_EXECUTED to fire earlier? Or should > > > there be an EVT_CACHE_QUERY_EXECUTION_STARTED for the query start, while > > > the old event would continue to work for query finish? > > > I think the new event needs to either reuse the old one, or be its mirror > > > for the query start. It also means that we probably should resolve the > > > issues you've listed. > > > > > > Would the event notification be synchronous? In which thread? > > Asynchronous > > > is generally preferred - would it work? > > > > > > What happens in case the event listener fails? > > > > > > Thanks, > > > Stan > > > > > > > On 16 Jul 2020, at 18:49, Denis Magda wrote: > > > > > > > > Taras, Yury, Ivan, > > > > > > > > Could you please join this thread and share your thoughts? Do we > > already > > > > have any plans on tracking of the DDL and DML queries? > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Wed, Jul 15, 2020 at 12:09 AM Max Timonin > > > > wrote: > > > > > > > >> Hi Denis, thanks for the answer! > > > >> > > > >> We already checked EVT_CACHE_QUERY_EXECUTED and found that it works > > > only in > > > >> cases: > > > >> 1. Scan queries and Select queries (common pattern is access to cache > > > >> data); > > > >> 2. This event triggers only if query execution succeeds, in case of > > > failure > > > >> while execution this event won't fire. > > > >> > > > >> Our additional requirements are to protocol queries: > > > >> 1. that aren't cache related (for example, alter user); > > > >> 2. that relate to multiple caches (while EVT_CACHE_QUERY_EXECUTED have > > > >> field cacheName related to specific cache); > > > >> 3. we need to protocol also DDL and DML queries. > > > >> > > > >> Regards, > > > >> Maksim > > > >> > > > >> On Tue, Jul 14, 2020 at 10:20 PM Denis Magda > > wrote: > > > >> > > > >>> Hi Max, > > > >>> > > > >>> Could you check if the EVT_CACHE_QUERY_EXECUTED event is what you're > > > >>> looking for? > > > >>> > > > >>> > > > >> > > > > > https://www.gridgain.com/docs/latest/developers-guide/events/events#cache-query-events > > > >>> > > > >>> - > > > >>> Denis > > > >>> > > > >>> > > > >>> On Fri, Jul 10, 2020 at 3:54 AM Max Timonin > > > > > >>> wrote: > > > >>> > > >
Re: Proposal of new event QUERY_EXECUTION_EVENT
Looks like EVT_CACHE_QUERY_EXECUTED just works for different use cases: 1. it relates to a specific cache (Event for SQL queries looks different as it could contain multiple caches or none of them); 2. Also the EVT_CACHE_QUERY_EXECUTED event fires multiple times for distributed queries, see GridMapQueryExecutor class (For SQL query it's required to fire once independently on how many nodes are affected). So there are different patterns for events. I think EVT_CACHE_QUERY_EXECUTED should not be deprecated or changed. > What happens in case the event listener fails? > Would the event notification be synchronous? It depends on how other events are implemented. As I see for the EVT_CACHE_QUERY_EXECUTED event - it's synchronous, and listener errors aren't handled. I think these questions are related to GridEventStorageManager as it just provides an API for recording events. Internal implementations (sync / async, error handling) is not related to an event, is it? > I have some doubts about provide text of a query even with hidden arguments, probably it should be configured due to it could lead to security leak Currently event EVT_CACHE_QUERY_EXECUTED provides a sql clause without limitations. If we're going to provide some restrictions it will require additional investigation. I see at least 2 configurations here: 1. Ignite can be configured to hide clase, params only or nothing for all listeners; 2. Only authorized listeners can subscribe to the event. Should we discuss this within this topic? On Mon, Jul 20, 2020 at 1:55 PM Юрий wrote: > In my opinion existing events EVT_CACHE_QUERY_EXECUTION_STARTED should be > deprecated and added two new for start and for end of queries which should > cover all SQL query types. > I have some doubts about provide text of a query even with hidden > arguments, probably it should be configured due to it could lead to > security leak > > пн, 20 июл. 2020 г. в 12:49, Stanislav Lukyanov : > > > Maksim, > > > > Can we change the EVT_CACHE_QUERY_EXECUTED to fire earlier? Or should > > there be an EVT_CACHE_QUERY_EXECUTION_STARTED for the query start, while > > the old event would continue to work for query finish? > > I think the new event needs to either reuse the old one, or be its mirror > > for the query start. It also means that we probably should resolve the > > issues you've listed. > > > > Would the event notification be synchronous? In which thread? > Asynchronous > > is generally preferred - would it work? > > > > What happens in case the event listener fails? > > > > Thanks, > > Stan > > > > > On 16 Jul 2020, at 18:49, Denis Magda wrote: > > > > > > Taras, Yury, Ivan, > > > > > > Could you please join this thread and share your thoughts? Do we > already > > > have any plans on tracking of the DDL and DML queries? > > > > > > - > > > Denis > > > > > > > > > On Wed, Jul 15, 2020 at 12:09 AM Max Timonin > > > wrote: > > > > > >> Hi Denis, thanks for the answer! > > >> > > >> We already checked EVT_CACHE_QUERY_EXECUTED and found that it works > > only in > > >> cases: > > >> 1. Scan queries and Select queries (common pattern is access to cache > > >> data); > > >> 2. This event triggers only if query execution succeeds, in case of > > failure > > >> while execution this event won't fire. > > >> > > >> Our additional requirements are to protocol queries: > > >> 1. that aren't cache related (for example, alter user); > > >> 2. that relate to multiple caches (while EVT_CACHE_QUERY_EXECUTED have > > >> field cacheName related to specific cache); > > >> 3. we need to protocol also DDL and DML queries. > > >> > > >> Regards, > > >> Maksim > > >> > > >> On Tue, Jul 14, 2020 at 10:20 PM Denis Magda > wrote: > > >> > > >>> Hi Max, > > >>> > > >>> Could you check if the EVT_CACHE_QUERY_EXECUTED event is what you're > > >>> looking for? > > >>> > > >>> > > >> > > > https://www.gridgain.com/docs/latest/developers-guide/events/events#cache-query-events > > >>> > > >>> - > > >>> Denis > > >>> > > >>> > > >>> On Fri, Jul 10, 2020 at 3:54 AM Max Timonin > > > >>> wrote: > > >>> > > Hi Igniters! > > > > We're going to protocol all input SQL queries from our users. > > Currently > > there is no such mechanism in Ignite to use for it. So we're > proposing > > >> to > > add a new event: QUERY_EXECUITION_EVENT. > > > > Requirements for the event: > > 1. If this event fires it means that a query is correct and will be > > executed (and failed only in exceptional cases); > > > > 2. Event fires for all query types; > > > > 3. Required fields are: > > - text of a query (with hidden arguments); > > - arguments of query; > > - query type; > > - node id. > > > > Looks that this event should go along with `runningQryMgr::register` > > in > > class `IgniteH2Indexing` as this method invoked for all input > queries > > >>> too. > > > > What do you think? > > > > Regards, > >
Re: Proposal of new event QUERY_EXECUTION_EVENT
In my opinion existing events EVT_CACHE_QUERY_EXECUTION_STARTED should be deprecated and added two new for start and for end of queries which should cover all SQL query types. I have some doubts about provide text of a query even with hidden arguments, probably it should be configured due to it could lead to security leak пн, 20 июл. 2020 г. в 12:49, Stanislav Lukyanov : > Maksim, > > Can we change the EVT_CACHE_QUERY_EXECUTED to fire earlier? Or should > there be an EVT_CACHE_QUERY_EXECUTION_STARTED for the query start, while > the old event would continue to work for query finish? > I think the new event needs to either reuse the old one, or be its mirror > for the query start. It also means that we probably should resolve the > issues you've listed. > > Would the event notification be synchronous? In which thread? Asynchronous > is generally preferred - would it work? > > What happens in case the event listener fails? > > Thanks, > Stan > > > On 16 Jul 2020, at 18:49, Denis Magda wrote: > > > > Taras, Yury, Ivan, > > > > Could you please join this thread and share your thoughts? Do we already > > have any plans on tracking of the DDL and DML queries? > > > > - > > Denis > > > > > > On Wed, Jul 15, 2020 at 12:09 AM Max Timonin > > wrote: > > > >> Hi Denis, thanks for the answer! > >> > >> We already checked EVT_CACHE_QUERY_EXECUTED and found that it works > only in > >> cases: > >> 1. Scan queries and Select queries (common pattern is access to cache > >> data); > >> 2. This event triggers only if query execution succeeds, in case of > failure > >> while execution this event won't fire. > >> > >> Our additional requirements are to protocol queries: > >> 1. that aren't cache related (for example, alter user); > >> 2. that relate to multiple caches (while EVT_CACHE_QUERY_EXECUTED have > >> field cacheName related to specific cache); > >> 3. we need to protocol also DDL and DML queries. > >> > >> Regards, > >> Maksim > >> > >> On Tue, Jul 14, 2020 at 10:20 PM Denis Magda wrote: > >> > >>> Hi Max, > >>> > >>> Could you check if the EVT_CACHE_QUERY_EXECUTED event is what you're > >>> looking for? > >>> > >>> > >> > https://www.gridgain.com/docs/latest/developers-guide/events/events#cache-query-events > >>> > >>> - > >>> Denis > >>> > >>> > >>> On Fri, Jul 10, 2020 at 3:54 AM Max Timonin > >>> wrote: > >>> > Hi Igniters! > > We're going to protocol all input SQL queries from our users. > Currently > there is no such mechanism in Ignite to use for it. So we're proposing > >> to > add a new event: QUERY_EXECUITION_EVENT. > > Requirements for the event: > 1. If this event fires it means that a query is correct and will be > executed (and failed only in exceptional cases); > > 2. Event fires for all query types; > > 3. Required fields are: > - text of a query (with hidden arguments); > - arguments of query; > - query type; > - node id. > > Looks that this event should go along with `runningQryMgr::register` > in > class `IgniteH2Indexing` as this method invoked for all input queries > >>> too. > > What do you think? > > Regards, > Maksim > > >>> > >> > > -- Живи с улыбкой! :D
Re: Proposal of new event QUERY_EXECUTION_EVENT
Maksim, Can we change the EVT_CACHE_QUERY_EXECUTED to fire earlier? Or should there be an EVT_CACHE_QUERY_EXECUTION_STARTED for the query start, while the old event would continue to work for query finish? I think the new event needs to either reuse the old one, or be its mirror for the query start. It also means that we probably should resolve the issues you've listed. Would the event notification be synchronous? In which thread? Asynchronous is generally preferred - would it work? What happens in case the event listener fails? Thanks, Stan > On 16 Jul 2020, at 18:49, Denis Magda wrote: > > Taras, Yury, Ivan, > > Could you please join this thread and share your thoughts? Do we already > have any plans on tracking of the DDL and DML queries? > > - > Denis > > > On Wed, Jul 15, 2020 at 12:09 AM Max Timonin > wrote: > >> Hi Denis, thanks for the answer! >> >> We already checked EVT_CACHE_QUERY_EXECUTED and found that it works only in >> cases: >> 1. Scan queries and Select queries (common pattern is access to cache >> data); >> 2. This event triggers only if query execution succeeds, in case of failure >> while execution this event won't fire. >> >> Our additional requirements are to protocol queries: >> 1. that aren't cache related (for example, alter user); >> 2. that relate to multiple caches (while EVT_CACHE_QUERY_EXECUTED have >> field cacheName related to specific cache); >> 3. we need to protocol also DDL and DML queries. >> >> Regards, >> Maksim >> >> On Tue, Jul 14, 2020 at 10:20 PM Denis Magda wrote: >> >>> Hi Max, >>> >>> Could you check if the EVT_CACHE_QUERY_EXECUTED event is what you're >>> looking for? >>> >>> >> https://www.gridgain.com/docs/latest/developers-guide/events/events#cache-query-events >>> >>> - >>> Denis >>> >>> >>> On Fri, Jul 10, 2020 at 3:54 AM Max Timonin >>> wrote: >>> Hi Igniters! We're going to protocol all input SQL queries from our users. Currently there is no such mechanism in Ignite to use for it. So we're proposing >> to add a new event: QUERY_EXECUITION_EVENT. Requirements for the event: 1. If this event fires it means that a query is correct and will be executed (and failed only in exceptional cases); 2. Event fires for all query types; 3. Required fields are: - text of a query (with hidden arguments); - arguments of query; - query type; - node id. Looks that this event should go along with `runningQryMgr::register` in class `IgniteH2Indexing` as this method invoked for all input queries >>> too. What do you think? Regards, Maksim >>> >>
Re: Proposal of new event QUERY_EXECUTION_EVENT
Taras, Yury, Ivan, Could you please join this thread and share your thoughts? Do we already have any plans on tracking of the DDL and DML queries? - Denis On Wed, Jul 15, 2020 at 12:09 AM Max Timonin wrote: > Hi Denis, thanks for the answer! > > We already checked EVT_CACHE_QUERY_EXECUTED and found that it works only in > cases: > 1. Scan queries and Select queries (common pattern is access to cache > data); > 2. This event triggers only if query execution succeeds, in case of failure > while execution this event won't fire. > > Our additional requirements are to protocol queries: > 1. that aren't cache related (for example, alter user); > 2. that relate to multiple caches (while EVT_CACHE_QUERY_EXECUTED have > field cacheName related to specific cache); > 3. we need to protocol also DDL and DML queries. > > Regards, > Maksim > > On Tue, Jul 14, 2020 at 10:20 PM Denis Magda wrote: > > > Hi Max, > > > > Could you check if the EVT_CACHE_QUERY_EXECUTED event is what you're > > looking for? > > > > > https://www.gridgain.com/docs/latest/developers-guide/events/events#cache-query-events > > > > - > > Denis > > > > > > On Fri, Jul 10, 2020 at 3:54 AM Max Timonin > > wrote: > > > > > Hi Igniters! > > > > > > We're going to protocol all input SQL queries from our users. Currently > > > there is no such mechanism in Ignite to use for it. So we're proposing > to > > > add a new event: QUERY_EXECUITION_EVENT. > > > > > > Requirements for the event: > > > 1. If this event fires it means that a query is correct and will be > > > executed (and failed only in exceptional cases); > > > > > > 2. Event fires for all query types; > > > > > > 3. Required fields are: > > > - text of a query (with hidden arguments); > > > - arguments of query; > > > - query type; > > > - node id. > > > > > > Looks that this event should go along with `runningQryMgr::register` in > > > class `IgniteH2Indexing` as this method invoked for all input queries > > too. > > > > > > What do you think? > > > > > > Regards, > > > Maksim > > > > > >
Re: Proposal of new event QUERY_EXECUTION_EVENT
Hi Denis, thanks for the answer! We already checked EVT_CACHE_QUERY_EXECUTED and found that it works only in cases: 1. Scan queries and Select queries (common pattern is access to cache data); 2. This event triggers only if query execution succeeds, in case of failure while execution this event won't fire. Our additional requirements are to protocol queries: 1. that aren't cache related (for example, alter user); 2. that relate to multiple caches (while EVT_CACHE_QUERY_EXECUTED have field cacheName related to specific cache); 3. we need to protocol also DDL and DML queries. Regards, Maksim On Tue, Jul 14, 2020 at 10:20 PM Denis Magda wrote: > Hi Max, > > Could you check if the EVT_CACHE_QUERY_EXECUTED event is what you're > looking for? > > https://www.gridgain.com/docs/latest/developers-guide/events/events#cache-query-events > > - > Denis > > > On Fri, Jul 10, 2020 at 3:54 AM Max Timonin > wrote: > > > Hi Igniters! > > > > We're going to protocol all input SQL queries from our users. Currently > > there is no such mechanism in Ignite to use for it. So we're proposing to > > add a new event: QUERY_EXECUITION_EVENT. > > > > Requirements for the event: > > 1. If this event fires it means that a query is correct and will be > > executed (and failed only in exceptional cases); > > > > 2. Event fires for all query types; > > > > 3. Required fields are: > > - text of a query (with hidden arguments); > > - arguments of query; > > - query type; > > - node id. > > > > Looks that this event should go along with `runningQryMgr::register` in > > class `IgniteH2Indexing` as this method invoked for all input queries > too. > > > > What do you think? > > > > Regards, > > Maksim > > >
Re: Proposal of new event QUERY_EXECUTION_EVENT
Hi Max, Could you check if the EVT_CACHE_QUERY_EXECUTED event is what you're looking for? https://www.gridgain.com/docs/latest/developers-guide/events/events#cache-query-events - Denis On Fri, Jul 10, 2020 at 3:54 AM Max Timonin wrote: > Hi Igniters! > > We're going to protocol all input SQL queries from our users. Currently > there is no such mechanism in Ignite to use for it. So we're proposing to > add a new event: QUERY_EXECUITION_EVENT. > > Requirements for the event: > 1. If this event fires it means that a query is correct and will be > executed (and failed only in exceptional cases); > > 2. Event fires for all query types; > > 3. Required fields are: > - text of a query (with hidden arguments); > - arguments of query; > - query type; > - node id. > > Looks that this event should go along with `runningQryMgr::register` in > class `IgniteH2Indexing` as this method invoked for all input queries too. > > What do you think? > > Regards, > Maksim >
Proposal of new event QUERY_EXECUTION_EVENT
Hi Igniters! We're going to protocol all input SQL queries from our users. Currently there is no such mechanism in Ignite to use for it. So we're proposing to add a new event: QUERY_EXECUITION_EVENT. Requirements for the event: 1. If this event fires it means that a query is correct and will be executed (and failed only in exceptional cases); 2. Event fires for all query types; 3. Required fields are: - text of a query (with hidden arguments); - arguments of query; - query type; - node id. Looks that this event should go along with `runningQryMgr::register` in class `IgniteH2Indexing` as this method invoked for all input queries too. What do you think? Regards, Maksim
Re[4]: Proposal: set default transaction timeout to 5 minutes
Of course, i just thinking about huge persistent installation and guys who not carefully reads Release Notes ) In case of long tx timeouts by design, they can easily fix default timeout with just one jmx call. >Zhenya, > >Can you please elaborate? >Why we need to change default TX timeout via JMX? It looks feasible and >perhaps may work as a hotfix for live deployments experiencing issues with >long transactions, but it's definitely a separate issue. > >On Fri, May 22, 2020 at 6:20 PM Zhenya Stanilovsky >< arzamas...@mail.ru.invalid > wrote: > >> >> Ivan, does global timeout change through jmx in scope of this ticket ? If >> so, can you add it ? Opposite we need additional ticket, i hope ? We >> still have no somehow store for jmx changed params, every one need to >> remember that cluster restart will reset this setting to default, in this >> case system param need to be appended. >> >> >> >> > https://issues.apache.org/jira/browse/IGNITE-13064 is raised with label >> >"newbie". >> > >> >On Tue, May 19, 2020 at 4:10 PM Ivan Rakov < ivan.glu...@gmail.com > >> wrote: >> > >> >> Support this idea in general but why 5 minutes and not less? >> >> >> >> This value looks to me greater than any value that can possibly affect >> >> existing deployments (existing long transactions may suddenly start to >> >> rollback), but less than reaction time of users that are only starting >> to >> >> get along with Ignite and suddenly experience TX deadlock. >> >> >> >> -- >> >> Best Regards, >> >> Ivan Rakov >> >> >> >> On Tue, May 19, 2020 at 10:31 AM Anton Vinogradov < a...@apache.org > >> wrote: >> >> >> >>> +1 >> >>> >> >>> On Mon, May 18, 2020 at 9:45 PM Sergey Antonov < >> antonovserge...@gmail.com >> >>> > >> >>> wrote: >> >>> >> >>> > +1 >> >>> > >> >>> > пн, 18 мая 2020 г. в 21:26, Andrey Mashenkov < >> >>> andrey.mashen...@gmail.com >: >> >>> > >> >>> > > +1 >> >>> > > >> >>> > > On Mon, May 18, 2020 at 9:19 PM Ivan Rakov < ivan.glu...@gmail.com >> > >> >>> > wrote: >> >>> > > >> >>> > > > Hi Igniters, >> >>> > > > >> >>> > > > I have a very simple proposal. Let's set default TX timeout to 5 >> >>> > minutes >> >>> > > > (right now it's 0 = no timeout). >> >>> > > > Pros: >> >>> > > > 1. Deadlock detection procedure is triggered on timeout. In case >> >>> user >> >>> > > will >> >>> > > > get into key-level deadlock, he'll be able to discover root cause >> >>> from >> >>> > > the >> >>> > > > logs (even though load will hang for a while) and skip step with >> >>> > googling >> >>> > > > and debugging. >> >>> > > > 2. Almost every system with transactions has timeout enabled by >> >>> > default. >> >>> > > > >> >>> > > > WDYT? >> >>> > > > >> >>> > > > -- >> >>> > > > Best Regards, >> >>> > > > Ivan Rakov >> >>> > > > >> >>> > > >> >>> > > >> >>> > > -- >> >>> > > Best regards, >> >>> > > Andrey V. Mashenkov >> >>> > > >> >>> > >> >>> > >> >>> > -- >> >>> > BR, Sergey Antonov >> >>> > >> >>> >> >> >> >> >> >>
Re: Re[2]: Proposal: set default transaction timeout to 5 minutes
Zhenya, Can you please elaborate? Why we need to change default TX timeout via JMX? It looks feasible and perhaps may work as a hotfix for live deployments experiencing issues with long transactions, but it's definitely a separate issue. On Fri, May 22, 2020 at 6:20 PM Zhenya Stanilovsky wrote: > > Ivan, does global timeout change through jmx in scope of this ticket ? If > so, can you add it ? Opposite we need additional ticket, i hope ? We > still have no somehow store for jmx changed params, every one need to > remember that cluster restart will reset this setting to default, in this > case system param need to be appended. > > > > >https://issues.apache.org/jira/browse/IGNITE-13064 is raised with label > >"newbie". > > > >On Tue, May 19, 2020 at 4:10 PM Ivan Rakov < ivan.glu...@gmail.com > > wrote: > > > >> Support this idea in general but why 5 minutes and not less? > >> > >> This value looks to me greater than any value that can possibly affect > >> existing deployments (existing long transactions may suddenly start to > >> rollback), but less than reaction time of users that are only starting > to > >> get along with Ignite and suddenly experience TX deadlock. > >> > >> -- > >> Best Regards, > >> Ivan Rakov > >> > >> On Tue, May 19, 2020 at 10:31 AM Anton Vinogradov < a...@apache.org > > wrote: > >> > >>> +1 > >>> > >>> On Mon, May 18, 2020 at 9:45 PM Sergey Antonov < > antonovserge...@gmail.com > >>> > > >>> wrote: > >>> > >>> > +1 > >>> > > >>> > пн, 18 мая 2020 г. в 21:26, Andrey Mashenkov < > >>> andrey.mashen...@gmail.com >: > >>> > > >>> > > +1 > >>> > > > >>> > > On Mon, May 18, 2020 at 9:19 PM Ivan Rakov < ivan.glu...@gmail.com > > > >>> > wrote: > >>> > > > >>> > > > Hi Igniters, > >>> > > > > >>> > > > I have a very simple proposal. Let's set default TX timeout to 5 > >>> > minutes > >>> > > > (right now it's 0 = no timeout). > >>> > > > Pros: > >>> > > > 1. Deadlock detection procedure is triggered on timeout. In case > >>> user > >>> > > will > >>> > > > get into key-level deadlock, he'll be able to discover root cause > >>> from > >>> > > the > >>> > > > logs (even though load will hang for a while) and skip step with > >>> > googling > >>> > > > and debugging. > >>> > > > 2. Almost every system with transactions has timeout enabled by > >>> > default. > >>> > > > > >>> > > > WDYT? > >>> > > > > >>> > > > -- > >>> > > > Best Regards, > >>> > > > Ivan Rakov > >>> > > > > >>> > > > >>> > > > >>> > > -- > >>> > > Best regards, > >>> > > Andrey V. Mashenkov > >>> > > > >>> > > >>> > > >>> > -- > >>> > BR, Sergey Antonov > >>> > > >>> > >> > > > >
Re[2]: Proposal: set default transaction timeout to 5 minutes
Ivan, does global timeout change through jmx in scope of this ticket ? If so, can you add it ? Opposite we need additional ticket, i hope ? We still have no somehow store for jmx changed params, every one need to remember that cluster restart will reset this setting to default, in this case system param need to be appended. >https://issues.apache.org/jira/browse/IGNITE-13064 is raised with label >"newbie". > >On Tue, May 19, 2020 at 4:10 PM Ivan Rakov < ivan.glu...@gmail.com > wrote: > >> Support this idea in general but why 5 minutes and not less? >> >> This value looks to me greater than any value that can possibly affect >> existing deployments (existing long transactions may suddenly start to >> rollback), but less than reaction time of users that are only starting to >> get along with Ignite and suddenly experience TX deadlock. >> >> -- >> Best Regards, >> Ivan Rakov >> >> On Tue, May 19, 2020 at 10:31 AM Anton Vinogradov < a...@apache.org > wrote: >> >>> +1 >>> >>> On Mon, May 18, 2020 at 9:45 PM Sergey Antonov < antonovserge...@gmail.com >>> > >>> wrote: >>> >>> > +1 >>> > >>> > пн, 18 мая 2020 г. в 21:26, Andrey Mashenkov < >>> andrey.mashen...@gmail.com >: >>> > >>> > > +1 >>> > > >>> > > On Mon, May 18, 2020 at 9:19 PM Ivan Rakov < ivan.glu...@gmail.com > >>> > wrote: >>> > > >>> > > > Hi Igniters, >>> > > > >>> > > > I have a very simple proposal. Let's set default TX timeout to 5 >>> > minutes >>> > > > (right now it's 0 = no timeout). >>> > > > Pros: >>> > > > 1. Deadlock detection procedure is triggered on timeout. In case >>> user >>> > > will >>> > > > get into key-level deadlock, he'll be able to discover root cause >>> from >>> > > the >>> > > > logs (even though load will hang for a while) and skip step with >>> > googling >>> > > > and debugging. >>> > > > 2. Almost every system with transactions has timeout enabled by >>> > default. >>> > > > >>> > > > WDYT? >>> > > > >>> > > > -- >>> > > > Best Regards, >>> > > > Ivan Rakov >>> > > > >>> > > >>> > > >>> > > -- >>> > > Best regards, >>> > > Andrey V. Mashenkov >>> > > >>> > >>> > >>> > -- >>> > BR, Sergey Antonov >>> > >>> >>
Re: Proposal: set default transaction timeout to 5 minutes
https://issues.apache.org/jira/browse/IGNITE-13064 is raised with label "newbie". On Tue, May 19, 2020 at 4:10 PM Ivan Rakov wrote: > Support this idea in general but why 5 minutes and not less? > > This value looks to me greater than any value that can possibly affect > existing deployments (existing long transactions may suddenly start to > rollback), but less than reaction time of users that are only starting to > get along with Ignite and suddenly experience TX deadlock. > > -- > Best Regards, > Ivan Rakov > > On Tue, May 19, 2020 at 10:31 AM Anton Vinogradov wrote: > >> +1 >> >> On Mon, May 18, 2020 at 9:45 PM Sergey Antonov > > >> wrote: >> >> > +1 >> > >> > пн, 18 мая 2020 г. в 21:26, Andrey Mashenkov < >> andrey.mashen...@gmail.com>: >> > >> > > +1 >> > > >> > > On Mon, May 18, 2020 at 9:19 PM Ivan Rakov >> > wrote: >> > > >> > > > Hi Igniters, >> > > > >> > > > I have a very simple proposal. Let's set default TX timeout to 5 >> > minutes >> > > > (right now it's 0 = no timeout). >> > > > Pros: >> > > > 1. Deadlock detection procedure is triggered on timeout. In case >> user >> > > will >> > > > get into key-level deadlock, he'll be able to discover root cause >> from >> > > the >> > > > logs (even though load will hang for a while) and skip step with >> > googling >> > > > and debugging. >> > > > 2. Almost every system with transactions has timeout enabled by >> > default. >> > > > >> > > > WDYT? >> > > > >> > > > -- >> > > > Best Regards, >> > > > Ivan Rakov >> > > > >> > > >> > > >> > > -- >> > > Best regards, >> > > Andrey V. Mashenkov >> > > >> > >> > >> > -- >> > BR, Sergey Antonov >> > >> >
Re: Proposal: set default transaction timeout to 5 minutes
> > Support this idea in general but why 5 minutes and not less? This value looks to me greater than any value that can possibly affect existing deployments (existing long transactions may suddenly start to rollback), but less than reaction time of users that are only starting to get along with Ignite and suddenly experience TX deadlock. -- Best Regards, Ivan Rakov On Tue, May 19, 2020 at 10:31 AM Anton Vinogradov wrote: > +1 > > On Mon, May 18, 2020 at 9:45 PM Sergey Antonov > wrote: > > > +1 > > > > пн, 18 мая 2020 г. в 21:26, Andrey Mashenkov >: > > > > > +1 > > > > > > On Mon, May 18, 2020 at 9:19 PM Ivan Rakov > > wrote: > > > > > > > Hi Igniters, > > > > > > > > I have a very simple proposal. Let's set default TX timeout to 5 > > minutes > > > > (right now it's 0 = no timeout). > > > > Pros: > > > > 1. Deadlock detection procedure is triggered on timeout. In case user > > > will > > > > get into key-level deadlock, he'll be able to discover root cause > from > > > the > > > > logs (even though load will hang for a while) and skip step with > > googling > > > > and debugging. > > > > 2. Almost every system with transactions has timeout enabled by > > default. > > > > > > > > WDYT? > > > > > > > > -- > > > > Best Regards, > > > > Ivan Rakov > > > > > > > > > > > > > -- > > > Best regards, > > > Andrey V. Mashenkov > > > > > > > > > -- > > BR, Sergey Antonov > > >
Re: Proposal: set default transaction timeout to 5 minutes
+1 On Mon, May 18, 2020 at 9:45 PM Sergey Antonov wrote: > +1 > > пн, 18 мая 2020 г. в 21:26, Andrey Mashenkov : > > > +1 > > > > On Mon, May 18, 2020 at 9:19 PM Ivan Rakov > wrote: > > > > > Hi Igniters, > > > > > > I have a very simple proposal. Let's set default TX timeout to 5 > minutes > > > (right now it's 0 = no timeout). > > > Pros: > > > 1. Deadlock detection procedure is triggered on timeout. In case user > > will > > > get into key-level deadlock, he'll be able to discover root cause from > > the > > > logs (even though load will hang for a while) and skip step with > googling > > > and debugging. > > > 2. Almost every system with transactions has timeout enabled by > default. > > > > > > WDYT? > > > > > > -- > > > Best Regards, > > > Ivan Rakov > > > > > > > > > -- > > Best regards, > > Andrey V. Mashenkov > > > > > -- > BR, Sergey Antonov >
Re: Proposal: set default transaction timeout to 5 minutes
+1 пн, 18 мая 2020 г. в 21:26, Andrey Mashenkov : > +1 > > On Mon, May 18, 2020 at 9:19 PM Ivan Rakov wrote: > > > Hi Igniters, > > > > I have a very simple proposal. Let's set default TX timeout to 5 minutes > > (right now it's 0 = no timeout). > > Pros: > > 1. Deadlock detection procedure is triggered on timeout. In case user > will > > get into key-level deadlock, he'll be able to discover root cause from > the > > logs (even though load will hang for a while) and skip step with googling > > and debugging. > > 2. Almost every system with transactions has timeout enabled by default. > > > > WDYT? > > > > -- > > Best Regards, > > Ivan Rakov > > > > > -- > Best regards, > Andrey V. Mashenkov > -- BR, Sergey Antonov
Re: Proposal: set default transaction timeout to 5 minutes
+1 On Mon, May 18, 2020 at 9:19 PM Ivan Rakov wrote: > Hi Igniters, > > I have a very simple proposal. Let's set default TX timeout to 5 minutes > (right now it's 0 = no timeout). > Pros: > 1. Deadlock detection procedure is triggered on timeout. In case user will > get into key-level deadlock, he'll be able to discover root cause from the > logs (even though load will hang for a while) and skip step with googling > and debugging. > 2. Almost every system with transactions has timeout enabled by default. > > WDYT? > > -- > Best Regards, > Ivan Rakov > -- Best regards, Andrey V. Mashenkov
Re: Proposal: set default transaction timeout to 5 minutes
+1 here. Hi Igniters, I have a very simple proposal. Let's set default TX timeout to 5 minutes (right now it's 0 = no timeout). Pros: 1. Deadlock detection procedure is triggered on timeout. In case user will get into key-level deadlock, he'll be able to discover root cause from the logs (even though load will hang for a while) and skip step with googling and debugging. 2. Almost every system with transactions has timeout enabled by default. WDYT? -- Best Regards, Ivan Rakov
Re: Proposal: set default transaction timeout to 5 minutes
Hi Ivan, Support this idea in general but why 5 minutes and not less? - Denis On Mon, May 18, 2020 at 11:19 AM Ivan Rakov wrote: > Hi Igniters, > > I have a very simple proposal. Let's set default TX timeout to 5 minutes > (right now it's 0 = no timeout). > Pros: > 1. Deadlock detection procedure is triggered on timeout. In case user will > get into key-level deadlock, he'll be able to discover root cause from the > logs (even though load will hang for a while) and skip step with googling > and debugging. > 2. Almost every system with transactions has timeout enabled by default. > > WDYT? > > -- > Best Regards, > Ivan Rakov >
Proposal: set default transaction timeout to 5 minutes
Hi Igniters, I have a very simple proposal. Let's set default TX timeout to 5 minutes (right now it's 0 = no timeout). Pros: 1. Deadlock detection procedure is triggered on timeout. In case user will get into key-level deadlock, he'll be able to discover root cause from the logs (even though load will hang for a while) and skip step with googling and debugging. 2. Almost every system with transactions has timeout enabled by default. WDYT? -- Best Regards, Ivan Rakov
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
Hello, I wanted to connect and discuss on the release process for ignite-extensions. As of today all our integrations since released together were able to run build based on latest snapshot for example the current build depends on 2.8.0-SNAPSHOT. If we are making ignite-extensions as separate project with different release cycle then it make sense to have dependencies on core modules based on released artifact for example the dependency for ignite-core would be 2.7.6 Please review and share your thoughts. PR https://github.com/apache/ignite-extensions/pull/1 Regards Saikat On Fri, Nov 15, 2019 at 6:52 PM Saikat Maitra wrote: > Hi Denis, > > Yes, sure I will start moving each extension one at a time and share > updates. > > I am currently working on Flink extension. > > Regards, > Saikat > > > > On Tue, Nov 12, 2019 at 1:55 PM Denis Magda wrote: > >> Saikat, >> >> Thanks for decoupling the task. Please ping the community once there is >> anything ready for a review or a further discussion. >> >> - >> Denis >> >> >> On Sat, Nov 9, 2019 at 3:58 PM Saikat Maitra >> wrote: >> >> > Hello, >> > >> > As discussed I have created the following jira issues for tracking the >> > migration work for ignite-extensions. >> > >> > Main issue : IEP-36: Modularization >> > https://issues.apache.org/jira/browse/IGNITE-12355 >> > >> > Sub-Tasks >> > >> > Migrate flink module to ignite-extensions >> > https://issues.apache.org/jira/browse/IGNITE-12356 >> > Migrate Twitter module to ignite-extensions >> > https://issues.apache.org/jira/browse/IGNITE-12357 >> > Migrate ZeroMQ module to ignite-extensions >> > https://issues.apache.org/jira/browse/IGNITE-12358 >> > Migrate RocketMQ module to ignite-extensions >> > https://issues.apache.org/jira/browse/IGNITE-12359 >> > Migrate Storm module to ignite-extensions >> > https://issues.apache.org/jira/browse/IGNITE-12360 >> > Migrate Flume module to ignite-extensions >> > https://issues.apache.org/jira/browse/IGNITE-12361 >> > Migrate MQTT module to ignite-extensions >> > https://issues.apache.org/jira/browse/IGNITE-12362 >> > Migrate Camel module to ignite-extensions >> > https://issues.apache.org/jira/browse/IGNITE-12363 >> > Migrate JMS module to ignite-extensions >> > https://issues.apache.org/jira/browse/IGNITE-12364 >> > >> > Regards, >> > Saikat >> > >> > On Fri, Nov 1, 2019 at 9:23 PM Saikat Maitra >> > wrote: >> > >> > > Ivan, Thank you for initialising the master branch, much appreciate >> it. >> > > >> > > Denis, Emmanouil, >> > > >> > > We use both local server and mockito to write the tests for flink. >> Incase >> > > of sink it is easier to use a local server mode and publish the data >> into >> > > Ignite Sink where as in case of Ignite used as data source we use >> mockito >> > > to mock Ignite events and Ignite clusters. >> > > >> > > Regards, >> > > Saikat >> > > >> > > >> > > >> > > On Fri, Nov 1, 2019 at 5:28 PM Emmanouil Gkatziouras < >> > gkatzio...@gmail.com> >> > > wrote: >> > > >> > >> Hi, >> > >> >> > >> I just took another look at the Kafka Implementation and I realised >> that >> > >> it >> > >> is a local implementation that is used on the tests (I thought it >> was a >> > >> server already existing somewhere). >> > >> It seems I might be able to spin up the Pub/Sub server locally (I >> found >> > an >> > >> official tool which might work), in the same way it is done for >> Kafka. >> > >> I will try to do so and come back with a pull request. >> > >> Kind regards >> > >> >> > >> *Emmanouil Gkatziouras* >> > >> https://egkatzioura.com/ | >> > >> https://www.linkedin.com/in/gkatziourasemmanouil/ >> > >> https://github.com/gkatzioura >> > >> >> > >> >> > >> On Fri, 1 Nov 2019 at 21:31, Denis Magda wrote: >> > >> >> > >> > Saikat, Roman, >> > >> > >> > >> > What's your thinking? I'm not sure we set any infrastructure to >> > validate >> > >> > our Kafka or Flink integrations. For instance, for
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
Hi Denis, Yes, sure I will start moving each extension one at a time and share updates. I am currently working on Flink extension. Regards, Saikat On Tue, Nov 12, 2019 at 1:55 PM Denis Magda wrote: > Saikat, > > Thanks for decoupling the task. Please ping the community once there is > anything ready for a review or a further discussion. > > - > Denis > > > On Sat, Nov 9, 2019 at 3:58 PM Saikat Maitra > wrote: > > > Hello, > > > > As discussed I have created the following jira issues for tracking the > > migration work for ignite-extensions. > > > > Main issue : IEP-36: Modularization > > https://issues.apache.org/jira/browse/IGNITE-12355 > > > > Sub-Tasks > > > > Migrate flink module to ignite-extensions > > https://issues.apache.org/jira/browse/IGNITE-12356 > > Migrate Twitter module to ignite-extensions > > https://issues.apache.org/jira/browse/IGNITE-12357 > > Migrate ZeroMQ module to ignite-extensions > > https://issues.apache.org/jira/browse/IGNITE-12358 > > Migrate RocketMQ module to ignite-extensions > > https://issues.apache.org/jira/browse/IGNITE-12359 > > Migrate Storm module to ignite-extensions > > https://issues.apache.org/jira/browse/IGNITE-12360 > > Migrate Flume module to ignite-extensions > > https://issues.apache.org/jira/browse/IGNITE-12361 > > Migrate MQTT module to ignite-extensions > > https://issues.apache.org/jira/browse/IGNITE-12362 > > Migrate Camel module to ignite-extensions > > https://issues.apache.org/jira/browse/IGNITE-12363 > > Migrate JMS module to ignite-extensions > > https://issues.apache.org/jira/browse/IGNITE-12364 > > > > Regards, > > Saikat > > > > On Fri, Nov 1, 2019 at 9:23 PM Saikat Maitra > > wrote: > > > > > Ivan, Thank you for initialising the master branch, much appreciate it. > > > > > > Denis, Emmanouil, > > > > > > We use both local server and mockito to write the tests for flink. > Incase > > > of sink it is easier to use a local server mode and publish the data > into > > > Ignite Sink where as in case of Ignite used as data source we use > mockito > > > to mock Ignite events and Ignite clusters. > > > > > > Regards, > > > Saikat > > > > > > > > > > > > On Fri, Nov 1, 2019 at 5:28 PM Emmanouil Gkatziouras < > > gkatzio...@gmail.com> > > > wrote: > > > > > >> Hi, > > >> > > >> I just took another look at the Kafka Implementation and I realised > that > > >> it > > >> is a local implementation that is used on the tests (I thought it was > a > > >> server already existing somewhere). > > >> It seems I might be able to spin up the Pub/Sub server locally (I > found > > an > > >> official tool which might work), in the same way it is done for Kafka. > > >> I will try to do so and come back with a pull request. > > >> Kind regards > > >> > > >> *Emmanouil Gkatziouras* > > >> https://egkatzioura.com/ | > > >> https://www.linkedin.com/in/gkatziourasemmanouil/ > > >> https://github.com/gkatzioura > > >> > > >> > > >> On Fri, 1 Nov 2019 at 21:31, Denis Magda wrote: > > >> > > >> > Saikat, Roman, > > >> > > > >> > What's your thinking? I'm not sure we set any infrastructure to > > validate > > >> > our Kafka or Flink integrations. For instance, for Flink we use > > Mockito > > >> > just to ensure that basic tests pass: > > >> > https://en.wikipedia.org/wiki/Mockito > > >> > > > >> > Our IP finders for AWS, GCE or K8 don't start up any environment for > > >> > testing. Instead, we create some smoke tests ensuring that the APIs > > are > > >> not > > >> > broken. > > >> > > > >> > - > > >> > Denis > > >> > > > >> > > > >> > On Fri, Nov 1, 2019 at 1:32 PM Emmanouil Gkatziouras < > > >> gkatzio...@gmail.com > > >> > > > > >> > wrote: > > >> > > > >> > > Hi all, > > >> > > > > >> > > That's great news! Yes I am ready to do a pull request on the new > > >> repo. > > >> > > I believe it is ok to create a ticket for the Pub/Sub proposal > [1]. > > >> > > My next question
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
Saikat, Thanks for decoupling the task. Please ping the community once there is anything ready for a review or a further discussion. - Denis On Sat, Nov 9, 2019 at 3:58 PM Saikat Maitra wrote: > Hello, > > As discussed I have created the following jira issues for tracking the > migration work for ignite-extensions. > > Main issue : IEP-36: Modularization > https://issues.apache.org/jira/browse/IGNITE-12355 > > Sub-Tasks > > Migrate flink module to ignite-extensions > https://issues.apache.org/jira/browse/IGNITE-12356 > Migrate Twitter module to ignite-extensions > https://issues.apache.org/jira/browse/IGNITE-12357 > Migrate ZeroMQ module to ignite-extensions > https://issues.apache.org/jira/browse/IGNITE-12358 > Migrate RocketMQ module to ignite-extensions > https://issues.apache.org/jira/browse/IGNITE-12359 > Migrate Storm module to ignite-extensions > https://issues.apache.org/jira/browse/IGNITE-12360 > Migrate Flume module to ignite-extensions > https://issues.apache.org/jira/browse/IGNITE-12361 > Migrate MQTT module to ignite-extensions > https://issues.apache.org/jira/browse/IGNITE-12362 > Migrate Camel module to ignite-extensions > https://issues.apache.org/jira/browse/IGNITE-12363 > Migrate JMS module to ignite-extensions > https://issues.apache.org/jira/browse/IGNITE-12364 > > Regards, > Saikat > > On Fri, Nov 1, 2019 at 9:23 PM Saikat Maitra > wrote: > > > Ivan, Thank you for initialising the master branch, much appreciate it. > > > > Denis, Emmanouil, > > > > We use both local server and mockito to write the tests for flink. Incase > > of sink it is easier to use a local server mode and publish the data into > > Ignite Sink where as in case of Ignite used as data source we use mockito > > to mock Ignite events and Ignite clusters. > > > > Regards, > > Saikat > > > > > > > > On Fri, Nov 1, 2019 at 5:28 PM Emmanouil Gkatziouras < > gkatzio...@gmail.com> > > wrote: > > > >> Hi, > >> > >> I just took another look at the Kafka Implementation and I realised that > >> it > >> is a local implementation that is used on the tests (I thought it was a > >> server already existing somewhere). > >> It seems I might be able to spin up the Pub/Sub server locally (I found > an > >> official tool which might work), in the same way it is done for Kafka. > >> I will try to do so and come back with a pull request. > >> Kind regards > >> > >> *Emmanouil Gkatziouras* > >> https://egkatzioura.com/ | > >> https://www.linkedin.com/in/gkatziourasemmanouil/ > >> https://github.com/gkatzioura > >> > >> > >> On Fri, 1 Nov 2019 at 21:31, Denis Magda wrote: > >> > >> > Saikat, Roman, > >> > > >> > What's your thinking? I'm not sure we set any infrastructure to > validate > >> > our Kafka or Flink integrations. For instance, for Flink we use > Mockito > >> > just to ensure that basic tests pass: > >> > https://en.wikipedia.org/wiki/Mockito > >> > > >> > Our IP finders for AWS, GCE or K8 don't start up any environment for > >> > testing. Instead, we create some smoke tests ensuring that the APIs > are > >> not > >> > broken. > >> > > >> > - > >> > Denis > >> > > >> > > >> > On Fri, Nov 1, 2019 at 1:32 PM Emmanouil Gkatziouras < > >> gkatzio...@gmail.com > >> > > > >> > wrote: > >> > > >> > > Hi all, > >> > > > >> > > That's great news! Yes I am ready to do a pull request on the new > >> repo. > >> > > I believe it is ok to create a ticket for the Pub/Sub proposal [1]. > >> > > My next question has to do with the CI and the integration tests. In > >> > order > >> > > for my tests to work, a local Pub/Sub server needs to be up and > >> running. > >> > > I tried to find any deployment scripts that set the infrastructure > >> needed > >> > > up and running (for example Kafka) but I was not successful on this > >> one. > >> > > How should I proceed on that? > >> > > > >> > > Kind regards > >> > > > >> > > [1] > >> > > > >> > > > >> > > >> > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Pub-Sub-Streamer-Implementation-tc43944.html > >> > > > >> > > *
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
Hello, As discussed I have created the following jira issues for tracking the migration work for ignite-extensions. Main issue : IEP-36: Modularization https://issues.apache.org/jira/browse/IGNITE-12355 Sub-Tasks Migrate flink module to ignite-extensions https://issues.apache.org/jira/browse/IGNITE-12356 Migrate Twitter module to ignite-extensions https://issues.apache.org/jira/browse/IGNITE-12357 Migrate ZeroMQ module to ignite-extensions https://issues.apache.org/jira/browse/IGNITE-12358 Migrate RocketMQ module to ignite-extensions https://issues.apache.org/jira/browse/IGNITE-12359 Migrate Storm module to ignite-extensions https://issues.apache.org/jira/browse/IGNITE-12360 Migrate Flume module to ignite-extensions https://issues.apache.org/jira/browse/IGNITE-12361 Migrate MQTT module to ignite-extensions https://issues.apache.org/jira/browse/IGNITE-12362 Migrate Camel module to ignite-extensions https://issues.apache.org/jira/browse/IGNITE-12363 Migrate JMS module to ignite-extensions https://issues.apache.org/jira/browse/IGNITE-12364 Regards, Saikat On Fri, Nov 1, 2019 at 9:23 PM Saikat Maitra wrote: > Ivan, Thank you for initialising the master branch, much appreciate it. > > Denis, Emmanouil, > > We use both local server and mockito to write the tests for flink. Incase > of sink it is easier to use a local server mode and publish the data into > Ignite Sink where as in case of Ignite used as data source we use mockito > to mock Ignite events and Ignite clusters. > > Regards, > Saikat > > > > On Fri, Nov 1, 2019 at 5:28 PM Emmanouil Gkatziouras > wrote: > >> Hi, >> >> I just took another look at the Kafka Implementation and I realised that >> it >> is a local implementation that is used on the tests (I thought it was a >> server already existing somewhere). >> It seems I might be able to spin up the Pub/Sub server locally (I found an >> official tool which might work), in the same way it is done for Kafka. >> I will try to do so and come back with a pull request. >> Kind regards >> >> *Emmanouil Gkatziouras* >> https://egkatzioura.com/ | >> https://www.linkedin.com/in/gkatziourasemmanouil/ >> https://github.com/gkatzioura >> >> >> On Fri, 1 Nov 2019 at 21:31, Denis Magda wrote: >> >> > Saikat, Roman, >> > >> > What's your thinking? I'm not sure we set any infrastructure to validate >> > our Kafka or Flink integrations. For instance, for Flink we use Mockito >> > just to ensure that basic tests pass: >> > https://en.wikipedia.org/wiki/Mockito >> > >> > Our IP finders for AWS, GCE or K8 don't start up any environment for >> > testing. Instead, we create some smoke tests ensuring that the APIs are >> not >> > broken. >> > >> > - >> > Denis >> > >> > >> > On Fri, Nov 1, 2019 at 1:32 PM Emmanouil Gkatziouras < >> gkatzio...@gmail.com >> > > >> > wrote: >> > >> > > Hi all, >> > > >> > > That's great news! Yes I am ready to do a pull request on the new >> repo. >> > > I believe it is ok to create a ticket for the Pub/Sub proposal [1]. >> > > My next question has to do with the CI and the integration tests. In >> > order >> > > for my tests to work, a local Pub/Sub server needs to be up and >> running. >> > > I tried to find any deployment scripts that set the infrastructure >> needed >> > > up and running (for example Kafka) but I was not successful on this >> one. >> > > How should I proceed on that? >> > > >> > > Kind regards >> > > >> > > [1] >> > > >> > > >> > >> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Pub-Sub-Streamer-Implementation-tc43944.html >> > > >> > > *Emmanouil Gkatziouras* >> > > https://egkatzioura.com/ | >> > > https://www.linkedin.com/in/gkatziourasemmanouil/ >> > > https://github.com/gkatzioura >> > > >> > > >> > > On Fri, 1 Nov 2019 at 06:52, Ivan Pavlukhin >> wrote: >> > > >> > > > Saikat, >> > > > >> > > > I initialized master branch with empty README file [1]. I suppose >> all >> > > > ignite committers have rights for push. >> > > > >> > > > [1] https://github.com/apache/ignite-extensions >> > > > >> > > > пт, 1 нояб. 2019 г. в 08:01, Saikat Maitra > >: >> > > > > >> > > > > Hello Dm
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
Ivan, Thank you for initialising the master branch, much appreciate it. Denis, Emmanouil, We use both local server and mockito to write the tests for flink. Incase of sink it is easier to use a local server mode and publish the data into Ignite Sink where as in case of Ignite used as data source we use mockito to mock Ignite events and Ignite clusters. Regards, Saikat On Fri, Nov 1, 2019 at 5:28 PM Emmanouil Gkatziouras wrote: > Hi, > > I just took another look at the Kafka Implementation and I realised that it > is a local implementation that is used on the tests (I thought it was a > server already existing somewhere). > It seems I might be able to spin up the Pub/Sub server locally (I found an > official tool which might work), in the same way it is done for Kafka. > I will try to do so and come back with a pull request. > Kind regards > > *Emmanouil Gkatziouras* > https://egkatzioura.com/ | > https://www.linkedin.com/in/gkatziourasemmanouil/ > https://github.com/gkatzioura > > > On Fri, 1 Nov 2019 at 21:31, Denis Magda wrote: > > > Saikat, Roman, > > > > What's your thinking? I'm not sure we set any infrastructure to validate > > our Kafka or Flink integrations. For instance, for Flink we use Mockito > > just to ensure that basic tests pass: > > https://en.wikipedia.org/wiki/Mockito > > > > Our IP finders for AWS, GCE or K8 don't start up any environment for > > testing. Instead, we create some smoke tests ensuring that the APIs are > not > > broken. > > > > - > > Denis > > > > > > On Fri, Nov 1, 2019 at 1:32 PM Emmanouil Gkatziouras < > gkatzio...@gmail.com > > > > > wrote: > > > > > Hi all, > > > > > > That's great news! Yes I am ready to do a pull request on the new repo. > > > I believe it is ok to create a ticket for the Pub/Sub proposal [1]. > > > My next question has to do with the CI and the integration tests. In > > order > > > for my tests to work, a local Pub/Sub server needs to be up and > running. > > > I tried to find any deployment scripts that set the infrastructure > needed > > > up and running (for example Kafka) but I was not successful on this > one. > > > How should I proceed on that? > > > > > > Kind regards > > > > > > [1] > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Pub-Sub-Streamer-Implementation-tc43944.html > > > > > > *Emmanouil Gkatziouras* > > > https://egkatzioura.com/ | > > > https://www.linkedin.com/in/gkatziourasemmanouil/ > > > https://github.com/gkatzioura > > > > > > > > > On Fri, 1 Nov 2019 at 06:52, Ivan Pavlukhin > wrote: > > > > > > > Saikat, > > > > > > > > I initialized master branch with empty README file [1]. I suppose all > > > > ignite committers have rights for push. > > > > > > > > [1] https://github.com/apache/ignite-extensions > > > > > > > > пт, 1 нояб. 2019 г. в 08:01, Saikat Maitra >: > > > > > > > > > > Hello Dmitriy, Denis > > > > > > > > > > Thank you for help in creating the repo. I can see it has synced in > > > > github > > > > > as well. > > > > > > > > > > Can you please add a sample readme.md file as the repo is empty I > am > > > > unable > > > > > to fork it? > > > > > > > > > > or let me check if I can directly commit a sample readme file from > > > local > > > > > then I should be able to fork this repo. > > > > > > > > > > I will start working on the migration for Flink, Camel, MQTT, etc. > > > > > > > > > > Emmanouil, please take a look and feel free to raise PR in this new > > > repo. > > > > > > > > > > Regards, > > > > > Saikat > > > > > > > > > > On Thu, Oct 31, 2019 at 3:14 PM Denis Magda > > wrote: > > > > > > > > > > > Dmitriy, thanks a lot for a quick turnaround! Saikat, please let > us > > > > know if > > > > > > anything else is needed. > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 1:12 PM Dmitriy Pavlov < > dpav...@apache.org > > > > > > > wr
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
Hi, I just took another look at the Kafka Implementation and I realised that it is a local implementation that is used on the tests (I thought it was a server already existing somewhere). It seems I might be able to spin up the Pub/Sub server locally (I found an official tool which might work), in the same way it is done for Kafka. I will try to do so and come back with a pull request. Kind regards *Emmanouil Gkatziouras* https://egkatzioura.com/ | https://www.linkedin.com/in/gkatziourasemmanouil/ https://github.com/gkatzioura On Fri, 1 Nov 2019 at 21:31, Denis Magda wrote: > Saikat, Roman, > > What's your thinking? I'm not sure we set any infrastructure to validate > our Kafka or Flink integrations. For instance, for Flink we use Mockito > just to ensure that basic tests pass: > https://en.wikipedia.org/wiki/Mockito > > Our IP finders for AWS, GCE or K8 don't start up any environment for > testing. Instead, we create some smoke tests ensuring that the APIs are not > broken. > > - > Denis > > > On Fri, Nov 1, 2019 at 1:32 PM Emmanouil Gkatziouras > > wrote: > > > Hi all, > > > > That's great news! Yes I am ready to do a pull request on the new repo. > > I believe it is ok to create a ticket for the Pub/Sub proposal [1]. > > My next question has to do with the CI and the integration tests. In > order > > for my tests to work, a local Pub/Sub server needs to be up and running. > > I tried to find any deployment scripts that set the infrastructure needed > > up and running (for example Kafka) but I was not successful on this one. > > How should I proceed on that? > > > > Kind regards > > > > [1] > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Pub-Sub-Streamer-Implementation-tc43944.html > > > > *Emmanouil Gkatziouras* > > https://egkatzioura.com/ | > > https://www.linkedin.com/in/gkatziourasemmanouil/ > > https://github.com/gkatzioura > > > > > > On Fri, 1 Nov 2019 at 06:52, Ivan Pavlukhin wrote: > > > > > Saikat, > > > > > > I initialized master branch with empty README file [1]. I suppose all > > > ignite committers have rights for push. > > > > > > [1] https://github.com/apache/ignite-extensions > > > > > > пт, 1 нояб. 2019 г. в 08:01, Saikat Maitra : > > > > > > > > Hello Dmitriy, Denis > > > > > > > > Thank you for help in creating the repo. I can see it has synced in > > > github > > > > as well. > > > > > > > > Can you please add a sample readme.md file as the repo is empty I am > > > unable > > > > to fork it? > > > > > > > > or let me check if I can directly commit a sample readme file from > > local > > > > then I should be able to fork this repo. > > > > > > > > I will start working on the migration for Flink, Camel, MQTT, etc. > > > > > > > > Emmanouil, please take a look and feel free to raise PR in this new > > repo. > > > > > > > > Regards, > > > > Saikat > > > > > > > > On Thu, Oct 31, 2019 at 3:14 PM Denis Magda > wrote: > > > > > > > > > Dmitriy, thanks a lot for a quick turnaround! Saikat, please let us > > > know if > > > > > anything else is needed. > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 1:12 PM Dmitriy Pavlov > > > > wrote: > > > > > > > > > > > Hi, I've created > > > > > > https://gitbox.apache.org/repos/asf/ignite-extensions.git > > > > > > > > > > > > It should be synced in a few minutes. > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > > > > чт, 31 окт. 2019 г. в 22:58, Denis Magda : > > > > > > > > > > > > > Ignite PMCs, can anybody create the repo for Saikat? I'm on the > > > road > > > > > and > > > > > > > can't do that. > > > > > > > > > > > > > > - > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 8:40 PM Saikat Maitra < > > > saikat.mai...@gmail.com > > > > > > > > > > > > > wrote: &
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
Saikat, Roman, What's your thinking? I'm not sure we set any infrastructure to validate our Kafka or Flink integrations. For instance, for Flink we use Mockito just to ensure that basic tests pass: https://en.wikipedia.org/wiki/Mockito Our IP finders for AWS, GCE or K8 don't start up any environment for testing. Instead, we create some smoke tests ensuring that the APIs are not broken. - Denis On Fri, Nov 1, 2019 at 1:32 PM Emmanouil Gkatziouras wrote: > Hi all, > > That's great news! Yes I am ready to do a pull request on the new repo. > I believe it is ok to create a ticket for the Pub/Sub proposal [1]. > My next question has to do with the CI and the integration tests. In order > for my tests to work, a local Pub/Sub server needs to be up and running. > I tried to find any deployment scripts that set the infrastructure needed > up and running (for example Kafka) but I was not successful on this one. > How should I proceed on that? > > Kind regards > > [1] > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Pub-Sub-Streamer-Implementation-tc43944.html > > *Emmanouil Gkatziouras* > https://egkatzioura.com/ | > https://www.linkedin.com/in/gkatziourasemmanouil/ > https://github.com/gkatzioura > > > On Fri, 1 Nov 2019 at 06:52, Ivan Pavlukhin wrote: > > > Saikat, > > > > I initialized master branch with empty README file [1]. I suppose all > > ignite committers have rights for push. > > > > [1] https://github.com/apache/ignite-extensions > > > > пт, 1 нояб. 2019 г. в 08:01, Saikat Maitra : > > > > > > Hello Dmitriy, Denis > > > > > > Thank you for help in creating the repo. I can see it has synced in > > github > > > as well. > > > > > > Can you please add a sample readme.md file as the repo is empty I am > > unable > > > to fork it? > > > > > > or let me check if I can directly commit a sample readme file from > local > > > then I should be able to fork this repo. > > > > > > I will start working on the migration for Flink, Camel, MQTT, etc. > > > > > > Emmanouil, please take a look and feel free to raise PR in this new > repo. > > > > > > Regards, > > > Saikat > > > > > > On Thu, Oct 31, 2019 at 3:14 PM Denis Magda wrote: > > > > > > > Dmitriy, thanks a lot for a quick turnaround! Saikat, please let us > > know if > > > > anything else is needed. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Thu, Oct 31, 2019 at 1:12 PM Dmitriy Pavlov > > wrote: > > > > > > > > > Hi, I've created > > > > > https://gitbox.apache.org/repos/asf/ignite-extensions.git > > > > > > > > > > It should be synced in a few minutes. > > > > > > > > > > Sincerely, > > > > > Dmitriy Pavlov > > > > > > > > > > чт, 31 окт. 2019 г. в 22:58, Denis Magda : > > > > > > > > > > > Ignite PMCs, can anybody create the repo for Saikat? I'm on the > > road > > > > and > > > > > > can't do that. > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 8:40 PM Saikat Maitra < > > saikat.mai...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I would need help from Ignite PMC member to create the new > > > > > > > repository ignite-extensions. > > > > > > > > > > > > > > Can you please create the repository here > > > > > https://selfserve.apache.org/ > > > > > > > > > > > > > > Regards, > > > > > > > Saikat > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 10:28 PM Saikat Maitra < > > > > > saikat.mai...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Hello Denis, > > > > > > > > > > > > > > > > Thank you for your response. > > > > > > > > > > > > > > > > I tried to request for new repository but the repository name > > is > > > > > > showing > > &g
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
Hi all, That's great news! Yes I am ready to do a pull request on the new repo. I believe it is ok to create a ticket for the Pub/Sub proposal [1]. My next question has to do with the CI and the integration tests. In order for my tests to work, a local Pub/Sub server needs to be up and running. I tried to find any deployment scripts that set the infrastructure needed up and running (for example Kafka) but I was not successful on this one. How should I proceed on that? Kind regards [1] http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Pub-Sub-Streamer-Implementation-tc43944.html *Emmanouil Gkatziouras* https://egkatzioura.com/ | https://www.linkedin.com/in/gkatziourasemmanouil/ https://github.com/gkatzioura On Fri, 1 Nov 2019 at 06:52, Ivan Pavlukhin wrote: > Saikat, > > I initialized master branch with empty README file [1]. I suppose all > ignite committers have rights for push. > > [1] https://github.com/apache/ignite-extensions > > пт, 1 нояб. 2019 г. в 08:01, Saikat Maitra : > > > > Hello Dmitriy, Denis > > > > Thank you for help in creating the repo. I can see it has synced in > github > > as well. > > > > Can you please add a sample readme.md file as the repo is empty I am > unable > > to fork it? > > > > or let me check if I can directly commit a sample readme file from local > > then I should be able to fork this repo. > > > > I will start working on the migration for Flink, Camel, MQTT, etc. > > > > Emmanouil, please take a look and feel free to raise PR in this new repo. > > > > Regards, > > Saikat > > > > On Thu, Oct 31, 2019 at 3:14 PM Denis Magda wrote: > > > > > Dmitriy, thanks a lot for a quick turnaround! Saikat, please let us > know if > > > anything else is needed. > > > > > > - > > > Denis > > > > > > > > > On Thu, Oct 31, 2019 at 1:12 PM Dmitriy Pavlov > wrote: > > > > > > > Hi, I've created > > > > https://gitbox.apache.org/repos/asf/ignite-extensions.git > > > > > > > > It should be synced in a few minutes. > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > чт, 31 окт. 2019 г. в 22:58, Denis Magda : > > > > > > > > > Ignite PMCs, can anybody create the repo for Saikat? I'm on the > road > > > and > > > > > can't do that. > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 8:40 PM Saikat Maitra < > saikat.mai...@gmail.com > > > > > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I would need help from Ignite PMC member to create the new > > > > > > repository ignite-extensions. > > > > > > > > > > > > Can you please create the repository here > > > > https://selfserve.apache.org/ > > > > > > > > > > > > Regards, > > > > > > Saikat > > > > > > > > > > > > On Wed, Oct 30, 2019 at 10:28 PM Saikat Maitra < > > > > saikat.mai...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Hello Denis, > > > > > > > > > > > > > > Thank you for your response. > > > > > > > > > > > > > > I tried to request for new repository but the repository name > is > > > > > showing > > > > > > > up as YourPMCs-ignite-extensions.git. I have reached out to > Apache > > > > > Infra > > > > > > > user email list to understand the process to create a new > > > repository. > > > > > > > > > > > > > > I will definitely help to migrate the other ignite extensions > to > > > the > > > > > new > > > > > > > repository once the repository is created. > > > > > > > > > > > > > > Regards, > > > > > > > Saikat > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
> >> > > >> > > > > > >> > > >> - > > > > > >> > > >> Denis > > > > > >> > > >> > > > > > >> > > >> > > > > > >> > > >> On Sat, Oct 26, 2019 at 10:06 PM Saikat Maitra < > > > > > >> > saikat.mai...@gmail.com> > > > > > >> > > >> wrote: > > > > > >> > > >> > > > > > >> > > >> > Hello Alexey, > > > > > >> > > >> > > > > > > >> > > >> > Thank you for your email. Yes, I am also aligned for > > > > > >> > ignite-extensions. > > > > > >> > > >> > > > > > > >> > > >> > If others are also ok we can create the new repository > > with > > > > > name > > > > > >> > > >> > ignite-extensions. > > > > > >> > > >> > > > > > > >> > > >> > Regards, > > > > > >> > > >> > Saikat > > > > > >> > > >> > > > > > > >> > > >> > On Sat, Oct 26, 2019 at 3:11 AM Alexey Zinoviev < > > > > > >> > zaleslaw@gmail.com > > > > > >> > > >> > > > > > > >> > > >> > wrote: > > > > > >> > > >> > > > > > > >> > > >> > > Vote for ignite-extensions (it's more widely than > > > > > >> > ignite-connectors) > > > > > >> > > >> > > > > > > > >> > > >> > > сб, 26 окт. 2019 г. в 05:52, Saikat Maitra < > > > > > >> > saikat.mai...@gmail.com>: > > > > > >> > > >> > > > > > > > >> > > >> > > > Hello Denis, Dmitriy > > > > > >> > > >> > > > > > > > > >> > > >> > > > Thank you for your reply. I am thinking when a new > > repo > > > > is > > > > > >> > created > > > > > >> > > >> that > > > > > >> > > >> > > > will not mean that the project will undergo Incubator > > > > > >> process , > > > > > >> > Is > > > > > >> > > >> > > > this correct? > > > > > >> > > >> > > > > > > > > >> > > >> > > > We actually want to just take few of our integrations > > > and > > > > > >> > release > > > > > >> > > >> them > > > > > >> > > >> > > > separately as part of this new git repository. We > > will > > > > > >> continue > > > > > >> > to > > > > > >> > > >> keep > > > > > >> > > >> > > the > > > > > >> > > >> > > > release group name and artifact name same. > > > > > >> > > >> > > > > > > > > >> > > >> > > > I will definitely help drive the initiative to > > migrate > > > > our > > > > > >> > > >> integrations > > > > > >> > > >> > > > into this new Ignite Extension repo. > > > > > >> > > >> > > > > > > > > >> > > >> > > > I seek help from our community to propose new name > > for > > > > > Ignite > > > > > >> > > >> Extension > > > > > >> > > >> > > > repository. > > > > > >> > > >> > > > > > > > > >> > > >> > > > Some ideas, I have are as follows: > > > > > >> > > >> > > > > > > > > >> > > >> > > > > > > > > >> > > >> > > >- ignite-extensions > > > > > >> > > >> > > >- ignite-sidecar > > > > > >> > > >>
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
t;> > Saikat > > > > >> > > >> > > > > > >> > > >> > On Sat, Oct 26, 2019 at 3:11 AM Alexey Zinoviev < > > > > >> > zaleslaw@gmail.com > > > > >> > > >> > > > > > >> > > >> > wrote: > > > > >> > > >> > > > > > >> > > >> > > Vote for ignite-extensions (it's more widely than > > > > >> > ignite-connectors) > > > > >> > > >> > > > > > > >> > > >> > > сб, 26 окт. 2019 г. в 05:52, Saikat Maitra < > > > > >> > saikat.mai...@gmail.com>: > > > > >> > > >> > > > > > > >> > > >> > > > Hello Denis, Dmitriy > > > > >> > > >> > > > > > > > >> > > >> > > > Thank you for your reply. I am thinking when a new > repo > > > is > > > > >> > created > > > > >> > > >> that > > > > >> > > >> > > > will not mean that the project will undergo Incubator > > > > >> process , > > > > >> > Is > > > > >> > > >> > > > this correct? > > > > >> > > >> > > > > > > > >> > > >> > > > We actually want to just take few of our integrations > > and > > > > >> > release > > > > >> > > >> them > > > > >> > > >> > > > separately as part of this new git repository. We > will > > > > >> continue > > > > >> > to > > > > >> > > >> keep > > > > >> > > >> > > the > > > > >> > > >> > > > release group name and artifact name same. > > > > >> > > >> > > > > > > > >> > > >> > > > I will definitely help drive the initiative to > migrate > > > our > > > > >> > > >> integrations > > > > >> > > >> > > > into this new Ignite Extension repo. > > > > >> > > >> > > > > > > > >> > > >> > > > I seek help from our community to propose new name > for > > > > Ignite > > > > >> > > >> Extension > > > > >> > > >> > > > repository. > > > > >> > > >> > > > > > > > >> > > >> > > > Some ideas, I have are as follows: > > > > >> > > >> > > > > > > > >> > > >> > > > > > > > >> > > >> > > >- ignite-extensions > > > > >> > > >> > > >- ignite-sidecar > > > > >> > > >> > > >- ignite-ext > > > > >> > > >> > > >- ignite-connectors > > > > >> > > >> > > > > > > > >> > > >> > > > > > > > >> > > >> > > > Regards, > > > > >> > > >> > > > Saikat > > > > >> > > >> > > > > > > > >> > > >> > > > On Fri, Oct 25, 2019 at 4:06 PM Dmitriy Pavlov < > > > > >> > dpav...@apache.org> > > > > >> > > >> > > wrote: > > > > >> > > >> > > > > > > > >> > > >> > > > > Hi Denis, > > > > >> > > >> > > > > > > > > >> > > >> > > > > any PMC member can create repository here > > > > >> > > >> > > > > https://selfserve.apache.org/ > > > > >> > > >> > > > > > > > > >> > > >> > > > > We just need to select repo names in advance. > > > > >> > > >> > > > > > > > > >> > > >> > > > > Sincerely, > > > > >> > > >> > > > > Dmitriy Pavlov > > > > >> > > >> > > > > > > > > >> > > >> > > > > пт, 25
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
sions versions. > > > >> > > > > > >> > > Regards, > > > >> > > Saikat > > > >> > > > > > >> > > > > > >> > > On Mon, Oct 28, 2019 at 7:14 PM Saikat Maitra < > > > >> saikat.mai...@gmail.com> > > > >> > > wrote: > > > >> > > > > > >> > > > Hi Denis, > > > >> > > > > > > >> > > > Yes, dedicated repository is also a good idea and we can > create > > > >> > submodules > > > >> > > > inside each specific repository for individual extensions. > > > >> > > > > > > >> > > > Regards, > > > >> > > > Saikat > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > On Mon, Oct 28, 2019 at 2:34 PM Denis Magda < > dma...@apache.org> > > > >> wrote: > > > >> > > > > > > >> > > >> Folks, > > > >> > > >> > > > >> > > >> What do you think about having a dedicated repository for > each > > > >> > extension > > > >> > > >> instead of a single one? It sounds complicated but might be > > > >> > worthwhile for > > > >> > > >> cases when an integration requires to support several > versions. > > > >> Take > > > >> > Spark > > > >> > > >> or Hibernate as an example, we already provide different > > versions > > > >> of > > > >> > > >> Ignite > > > >> > > >> packages for various Spark/Hibernate versions. It will be > > easier > > > to > > > >> > handle > > > >> > > >> if Spark or Hibernate had their own repos. > > > >> > > >> > > > >> > > >> - > > > >> > > >> Denis > > > >> > > >> > > > >> > > >> > > > >> > > >> On Sat, Oct 26, 2019 at 10:06 PM Saikat Maitra < > > > >> > saikat.mai...@gmail.com> > > > >> > > >> wrote: > > > >> > > >> > > > >> > > >> > Hello Alexey, > > > >> > > >> > > > > >> > > >> > Thank you for your email. Yes, I am also aligned for > > > >> > ignite-extensions. > > > >> > > >> > > > > >> > > >> > If others are also ok we can create the new repository with > > > name > > > >> > > >> > ignite-extensions. > > > >> > > >> > > > > >> > > >> > Regards, > > > >> > > >> > Saikat > > > >> > > >> > > > > >> > > >> > On Sat, Oct 26, 2019 at 3:11 AM Alexey Zinoviev < > > > >> > zaleslaw@gmail.com > > > >> > > >> > > > > >> > > >> > wrote: > > > >> > > >> > > > > >> > > >> > > Vote for ignite-extensions (it's more widely than > > > >> > ignite-connectors) > > > >> > > >> > > > > > >> > > >> > > сб, 26 окт. 2019 г. в 05:52, Saikat Maitra < > > > >> > saikat.mai...@gmail.com>: > > > >> > > >> > > > > > >> > > >> > > > Hello Denis, Dmitriy > > > >> > > >> > > > > > > >> > > >> > > > Thank you for your reply. I am thinking when a new repo > > is > > > >> > created > > > >> > > >> that > > > >> > > >> > > > will not mean that the project will undergo Incubator > > > >> process , > > > >> > Is > > > >> > > >> > > > this correct? > > > >> > > >> > > > > > > >> > > >> > > > We actually want to just take few of our integrations > and > > > >> > release > > > >> > > >> them > > > >> > > >&g
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
gt; > > > > > >> > > > > > >> > > > On Mon, Oct 28, 2019 at 2:34 PM Denis Magda > > >> wrote: > > >> > > > > > >> > > >> Folks, > > >> > > >> > > >> > > >> What do you think about having a dedicated repository for each > > >> > extension > > >> > > >> instead of a single one? It sounds complicated but might be > > >> > worthwhile for > > >> > > >> cases when an integration requires to support several versions. > > >> Take > > >> > Spark > > >> > > >> or Hibernate as an example, we already provide different > versions > > >> of > > >> > > >> Ignite > > >> > > >> packages for various Spark/Hibernate versions. It will be > easier > > to > > >> > handle > > >> > > >> if Spark or Hibernate had their own repos. > > >> > > >> > > >> > > >> - > > >> > > >> Denis > > >> > > >> > > >> > > >> > > >> > > >> On Sat, Oct 26, 2019 at 10:06 PM Saikat Maitra < > > >> > saikat.mai...@gmail.com> > > >> > > >> wrote: > > >> > > >> > > >> > > >> > Hello Alexey, > > >> > > >> > > > >> > > >> > Thank you for your email. Yes, I am also aligned for > > >> > ignite-extensions. > > >> > > >> > > > >> > > >> > If others are also ok we can create the new repository with > > name > > >> > > >> > ignite-extensions. > > >> > > >> > > > >> > > >> > Regards, > > >> > > >> > Saikat > > >> > > >> > > > >> > > >> > On Sat, Oct 26, 2019 at 3:11 AM Alexey Zinoviev < > > >> > zaleslaw@gmail.com > > >> > > >> > > > >> > > >> > wrote: > > >> > > >> > > > >> > > >> > > Vote for ignite-extensions (it's more widely than > > >> > ignite-connectors) > > >> > > >> > > > > >> > > >> > > сб, 26 окт. 2019 г. в 05:52, Saikat Maitra < > > >> > saikat.mai...@gmail.com>: > > >> > > >> > > > > >> > > >> > > > Hello Denis, Dmitriy > > >> > > >> > > > > > >> > > >> > > > Thank you for your reply. I am thinking when a new repo > is > > >> > created > > >> > > >> that > > >> > > >> > > > will not mean that the project will undergo Incubator > > >> process , > > >> > Is > > >> > > >> > > > this correct? > > >> > > >> > > > > > >> > > >> > > > We actually want to just take few of our integrations and > > >> > release > > >> > > >> them > > >> > > >> > > > separately as part of this new git repository. We will > > >> continue > > >> > to > > >> > > >> keep > > >> > > >> > > the > > >> > > >> > > > release group name and artifact name same. > > >> > > >> > > > > > >> > > >> > > > I will definitely help drive the initiative to migrate > our > > >> > > >> integrations > > >> > > >> > > > into this new Ignite Extension repo. > > >> > > >> > > > > > >> > > >> > > > I seek help from our community to propose new name for > > Ignite > > >> > > >> Extension > > >> > > >> > > > repository. > > >> > > >> > > > > > >> > > >> > > > Some ideas, I have are as follows: > > >> > > >> > > > > > >> > > >> > > > > > >> > > >> > > >- ignite-extensions > > >> > > >> > > >- ig
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
ernate versions. It will be easier > to > >> > handle > >> > > >> if Spark or Hibernate had their own repos. > >> > > >> > >> > > >> - > >> > > >> Denis > >> > > >> > >> > > >> > >> > > >> On Sat, Oct 26, 2019 at 10:06 PM Saikat Maitra < > >> > saikat.mai...@gmail.com> > >> > > >> wrote: > >> > > >> > >> > > >> > Hello Alexey, > >> > > >> > > >> > > >> > Thank you for your email. Yes, I am also aligned for > >> > ignite-extensions. > >> > > >> > > >> > > >> > If others are also ok we can create the new repository with > name > >> > > >> > ignite-extensions. > >> > > >> > > >> > > >> > Regards, > >> > > >> > Saikat > >> > > >> > > >> > > >> > On Sat, Oct 26, 2019 at 3:11 AM Alexey Zinoviev < > >> > zaleslaw@gmail.com > >> > > >> > > >> > > >> > wrote: > >> > > >> > > >> > > >> > > Vote for ignite-extensions (it's more widely than > >> > ignite-connectors) > >> > > >> > > > >> > > >> > > сб, 26 окт. 2019 г. в 05:52, Saikat Maitra < > >> > saikat.mai...@gmail.com>: > >> > > >> > > > >> > > >> > > > Hello Denis, Dmitriy > >> > > >> > > > > >> > > >> > > > Thank you for your reply. I am thinking when a new repo is > >> > created > >> > > >> that > >> > > >> > > > will not mean that the project will undergo Incubator > >> process , > >> > Is > >> > > >> > > > this correct? > >> > > >> > > > > >> > > >> > > > We actually want to just take few of our integrations and > >> > release > >> > > >> them > >> > > >> > > > separately as part of this new git repository. We will > >> continue > >> > to > >> > > >> keep > >> > > >> > > the > >> > > >> > > > release group name and artifact name same. > >> > > >> > > > > >> > > >> > > > I will definitely help drive the initiative to migrate our > >> > > >> integrations > >> > > >> > > > into this new Ignite Extension repo. > >> > > >> > > > > >> > > >> > > > I seek help from our community to propose new name for > Ignite > >> > > >> Extension > >> > > >> > > > repository. > >> > > >> > > > > >> > > >> > > > Some ideas, I have are as follows: > >> > > >> > > > > >> > > >> > > > > >> > > >> > > >- ignite-extensions > >> > > >> > > >- ignite-sidecar > >> > > >> > > >- ignite-ext > >> > > >> > > >- ignite-connectors > >> > > >> > > > > >> > > >> > > > > >> > > >> > > > Regards, > >> > > >> > > > Saikat > >> > > >> > > > > >> > > >> > > > On Fri, Oct 25, 2019 at 4:06 PM Dmitriy Pavlov < > >> > dpav...@apache.org> > >> > > >> > > wrote: > >> > > >> > > > > >> > > >> > > > > Hi Denis, > >> > > >> > > > > > >> > > >> > > > > any PMC member can create repository here > >> > > >> > > > > https://selfserve.apache.org/ > >> > > >> > > > > > >> > > >> > > > > We just need to select repo names in advance. > >> > > >> > > > > > >> > > >> > > > > Sincerely, > >> > > >> > > > > Dmitriy Pavlov > >> > > >> > > > &
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
with name >> > > >> > ignite-extensions. >> > > >> > >> > > >> > Regards, >> > > >> > Saikat >> > > >> > >> > > >> > On Sat, Oct 26, 2019 at 3:11 AM Alexey Zinoviev < >> > zaleslaw@gmail.com >> > > >> > >> > > >> > wrote: >> > > >> > >> > > >> > > Vote for ignite-extensions (it's more widely than >> > ignite-connectors) >> > > >> > > >> > > >> > > сб, 26 окт. 2019 г. в 05:52, Saikat Maitra < >> > saikat.mai...@gmail.com>: >> > > >> > > >> > > >> > > > Hello Denis, Dmitriy >> > > >> > > > >> > > >> > > > Thank you for your reply. I am thinking when a new repo is >> > created >> > > >> that >> > > >> > > > will not mean that the project will undergo Incubator >> process , >> > Is >> > > >> > > > this correct? >> > > >> > > > >> > > >> > > > We actually want to just take few of our integrations and >> > release >> > > >> them >> > > >> > > > separately as part of this new git repository. We will >> continue >> > to >> > > >> keep >> > > >> > > the >> > > >> > > > release group name and artifact name same. >> > > >> > > > >> > > >> > > > I will definitely help drive the initiative to migrate our >> > > >> integrations >> > > >> > > > into this new Ignite Extension repo. >> > > >> > > > >> > > >> > > > I seek help from our community to propose new name for Ignite >> > > >> Extension >> > > >> > > > repository. >> > > >> > > > >> > > >> > > > Some ideas, I have are as follows: >> > > >> > > > >> > > >> > > > >> > > >> > > >- ignite-extensions >> > > >> > > >- ignite-sidecar >> > > >> > > >- ignite-ext >> > > >> > > >- ignite-connectors >> > > >> > > > >> > > >> > > > >> > > >> > > > Regards, >> > > >> > > > Saikat >> > > >> > > > >> > > >> > > > On Fri, Oct 25, 2019 at 4:06 PM Dmitriy Pavlov < >> > dpav...@apache.org> >> > > >> > > wrote: >> > > >> > > > >> > > >> > > > > Hi Denis, >> > > >> > > > > >> > > >> > > > > any PMC member can create repository here >> > > >> > > > > https://selfserve.apache.org/ >> > > >> > > > > >> > > >> > > > > We just need to select repo names in advance. >> > > >> > > > > >> > > >> > > > > Sincerely, >> > > >> > > > > Dmitriy Pavlov >> > > >> > > > > >> > > >> > > > > пт, 25 окт. 2019 г. в 23:57, Denis Magda < >> dma...@apache.org>: >> > > >> > > > > >> > > >> > > > > > Saikat, sounds great. >> > > >> > > > > > >> > > >> > > > > > As long as you're already driving this initiative, could >> you >> > > >> please >> > > >> > > > check >> > > >> > > > > > with ASF Infra how to put this approach in place? Will >> we be >> > > >> able >> > > >> > to >> > > >> > > > > create >> > > >> > > > > > several additional repositories for extensions and >> release >> > them >> > > >> as >> > > >> > > part >> > > >> > > > > of >> > > >> > > > > > the Ignite project? >> > > >> > > > > > >> > > >> >
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
>> > > > Thank you for your reply. I am thinking when a new repo is > > created > > > >> that > > > >> > > > will not mean that the project will undergo Incubator process > , > > Is > > > >> > > > this correct? > > > >> > > > > > > >> > > > We actually want to just take few of our integrations and > > release > > > >> them > > > >> > > > separately as part of this new git repository. We will > continue > > to > > > >> keep > > > >> > > the > > > >> > > > release group name and artifact name same. > > > >> > > > > > > >> > > > I will definitely help drive the initiative to migrate our > > > >> integrations > > > >> > > > into this new Ignite Extension repo. > > > >> > > > > > > >> > > > I seek help from our community to propose new name for Ignite > > > >> Extension > > > >> > > > repository. > > > >> > > > > > > >> > > > Some ideas, I have are as follows: > > > >> > > > > > > >> > > > > > > >> > > >- ignite-extensions > > > >> > > >- ignite-sidecar > > > >> > > >- ignite-ext > > > >> > > >- ignite-connectors > > > >> > > > > > > >> > > > > > > >> > > > Regards, > > > >> > > > Saikat > > > >> > > > > > > >> > > > On Fri, Oct 25, 2019 at 4:06 PM Dmitriy Pavlov < > > dpav...@apache.org> > > > >> > > wrote: > > > >> > > > > > > >> > > > > Hi Denis, > > > >> > > > > > > > >> > > > > any PMC member can create repository here > > > >> > > > > https://selfserve.apache.org/ > > > >> > > > > > > > >> > > > > We just need to select repo names in advance. > > > >> > > > > > > > >> > > > > Sincerely, > > > >> > > > > Dmitriy Pavlov > > > >> > > > > > > > >> > > > > пт, 25 окт. 2019 г. в 23:57, Denis Magda >: > > > >> > > > > > > > >> > > > > > Saikat, sounds great. > > > >> > > > > > > > > >> > > > > > As long as you're already driving this initiative, could > you > > > >> please > > > >> > > > check > > > >> > > > > > with ASF Infra how to put this approach in place? Will we > be > > > >> able > > > >> > to > > > >> > > > > create > > > >> > > > > > several additional repositories for extensions and release > > them > > > >> as > > > >> > > part > > > >> > > > > of > > > >> > > > > > the Ignite project? > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > - > > > >> > > > > > Denis > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > On Thu, Oct 24, 2019 at 7:18 PM Saikat Maitra < > > > >> > > saikat.mai...@gmail.com > > > >> > > > > > > > >> > > > > > wrote: > > > >> > > > > > > > > >> > > > > > > Hi Denis, > > > >> > > > > > > > > > >> > > > > > > Yes, I see it now as I think more about it, I like > option > > - > > > >> 0. I > > > >> > am > > > >> > > > > > > thinking from a new member and a contributor perspective > > for > > > >> > Ignite > > > >> > > > > > > project, I would very much like my PR and proposal to be > > > >> accepted > > > >> > > > > within > > > >> > > > > > > Ignite community. > > &g
Re: [DISCUSS] Proposal for Ignite Extensions as a separate Bahir module or Incubator project
y to propose new name for Ignite > > >> Extension > > >> > > > repository. > > >> > > > > > >> > > > Some ideas, I have are as follows: > > >> > > > > > >> > > > > > >> > > >- ignite-extensions > > >> > > >- ignite-sidecar > > >> > > >- ignite-ext > > >> > > >- ignite-connectors > > >> > > > > > >> > > > > > >> > > > Regards, > > >> > > > Saikat > > >> > > > > > >> > > > On Fri, Oct 25, 2019 at 4:06 PM Dmitriy Pavlov < > dpav...@apache.org> > > >> > > wrote: > > >> > > > > > >> > > > > Hi Denis, > > >> > > > > > > >> > > > > any PMC member can create repository here > > >> > > > > https://selfserve.apache.org/ > > >> > > > > > > >> > > > > We just need to select repo names in advance. > > >> > > > > > > >> > > > > Sincerely, > > >> > > > > Dmitriy Pavlov > > >> > > > > > > >> > > > > пт, 25 окт. 2019 г. в 23:57, Denis Magda : > > >> > > > > > > >> > > > > > Saikat, sounds great. > > >> > > > > > > > >> > > > > > As long as you're already driving this initiative, could you > > >> please > > >> > > > check > > >> > > > > > with ASF Infra how to put this approach in place? Will we be > > >> able > > >> > to > > >> > > > > create > > >> > > > > > several additional repositories for extensions and release > them > > >> as > > >> > > part > > >> > > > > of > > >> > > > > > the Ignite project? > > >> > > > > > > > >> > > > > > > > >> > > > > > - > > >> > > > > > Denis > > >> > > > > > > > >> > > > > > > > >> > > > > > On Thu, Oct 24, 2019 at 7:18 PM Saikat Maitra < > > >> > > saikat.mai...@gmail.com > > >> > > > > > > >> > > > > > wrote: > > >> > > > > > > > >> > > > > > > Hi Denis, > > >> > > > > > > > > >> > > > > > > Yes, I see it now as I think more about it, I like option > - > > >> 0. I > > >> > am > > >> > > > > > > thinking from a new member and a contributor perspective > for > > >> > Ignite > > >> > > > > > > project, I would very much like my PR and proposal to be > > >> accepted > > >> > > > > within > > >> > > > > > > Ignite community. > > >> > > > > > > > > >> > > > > > > Regards, > > >> > > > > > > Saikat > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > On Thu, Oct 24, 2019 at 1:56 PM Denis Magda < > > >> dma...@apache.org> > > >> > > > wrote: > > >> > > > > > > > > >> > > > > > > > Exactly, Dmitry found the right word for the reason why > > >> > option-0 > > >> > > > > might > > >> > > > > > be > > >> > > > > > > > the best one - to avoid the Ignite community *split*. > All > > >> those > > >> > > who > > >> > > > > > will > > >> > > > > > > be > > >> > > > > > > > contributing to integrations and extensions need to be > able > > >> to > > >> > > > earn a > > >> > > > > > > > status of an Ignite committer and PMC members. > Otherwise, > > >> I'm > > >> > not >
