Re: ignite-extenisions naming policy
Hi Petr, Can you please share if the tag you are referring to is git release tag or changes required in some other file? If it is git release tag we can follow the naming convention as ignite-spring-boot-autoconfigure-ext-1.0.1 going forward. Regards, Saikat On Fri, Oct 9, 2020 at 5:11 AM Petr Ivanov wrote: > > Hi, Igniters. > > > While working with ignite-extensions, I've faced some mismatch with naming > of tag for extension: > > Artifact is 'ignite-spring-boot-autoconfigure-ext' > Module is 'spring-boot-autoconfigure-ext' > But tag is 'ignite-spring-boot-1.0.0' > > > Can we: > 1. match tag name with either module artifactID or maven name? > 2. replace current ignite-spring-boot-1.0.0 with the or add new correct > one?
Re: Migration of spring-data modules to ignite-extensions
Hi Mikhail, Also once the changes are complete please add modules details and Testsuites in the teamcity build config https://ci.ignite.apache.org/admin/editBuildParams.html?id=buildType:Tests_IgniteExtensions_Build Regards, Saikat On Fri, Oct 9, 2020 at 7:09 AM Mikhail Petrov wrote: > Ilya, I haven't meant that removal of spring-data from Ignite main > repository should be done before the 2.9 release and be included in it. > > Migration of spring-data to ignite-extensions could help us to make > SpringData integration updates available for users earlier then the next > Ignite release. For example adding support of thin client for SpringData. > > > On 09.10.2020 14:25, Ilya Kasnacheev wrote: > > Hello! > > > > I mean the Apache Ignite 2.9 release and Ignite Extensions 1.0 release. > > Once we get that in the wild and gather a few months of feedback (or lack > > thereof) then we can go on with it. > > > > Regards, >
Re: Migration of spring-data modules to ignite-extensions
Hi Nikolay, I have reviewed the PR and shared my comments. Ilya, My thoughts are that as soon the ignite 2.9.0 is released we should be able to release the ignite-extensions module 1st version pointing to ignite-core 2.9.0 version. So, for example ignite-flink-ext version 1.0.0 will be dependent on ignite-core version 2.9.0 etc. Denis, I am thinking that users will just start consuming new to be released extensions modules like for example kafka would be as following: org.apache.ignite ignite-kafka-ext 1.0.0 Regards, Saikat On Fri, Oct 9, 2020 at 3:58 PM Denis Magda wrote: > How do we release all the modules that have already been moved to the > extensions repository? > https://github.com/apache/ignite-extensions/tree/master/modules > > For instance, when 2.9 comes out and the users start bumping up their > Ignite versions in pom.xml, what should they set for Kafka, camel, etc. > that are already in the extensions? 2.9 or..? > > > - > Denis > > > On Fri, Oct 9, 2020 at 8:54 AM Ilya Kasnacheev > wrote: > > > Hello! > > > > In any case, we need to release *something* and wait for it to be used by > > actual users. > > > > Currently this is not happening since 2.8.1 contains all extensions as > > modules. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пт, 9 окт. 2020 г. в 15:12, Nikolay Izhikov : > > > > > Ilya. > > > > > > My understanding is the following - there is no such thing as «Ignite > > > Extensions release» > > > We can and should release each module separately. > > > > > > You can take as an example - spring-boot-autoconfigure extension > release. > > > I made it without releasing any other modules. > > > > > > This mean - we can release spring-data modules as frequently as we > want. > > > No correlation with the other extensions. > > > > > > > > > > 9 окт. 2020 г., в 14:25, Ilya Kasnacheev > > > написал(а): > > > > > > > > Hello! > > > > > > > > I mean the Apache Ignite 2.9 release and Ignite Extensions 1.0 > release. > > > > Once we get that in the wild and gather a few months of feedback (or > > lack > > > > thereof) then we can go on with it. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > пт, 9 окт. 2020 г. в 12:42, Nikolay Izhikov : > > > > > > > >> Ilya, we should move modules that is not related to Ignite core to > > > >> extension. > > > >> We shouldn’t support all possible integrations in the Ignite itself. > > > >> > > > >>> I would argue that it should only moved to extensions last, > > > >>> when this process is debugged thoroughly and when we have at least > > one > > > >> "essentials + extensions" release shipped with feedback. > > > >> > > > >> Each extension should be released separately. > > > >> What is «essentials + extensions» release do you have in mind? > > > >> > > > >> > > > >> Moreover, ignite-spring-data release is not related to any Ignite > > > releases. > > > >> Why do we have to wait Ignite release to get spring-data fixes or > > > updates? > > > >> > > > >>> 9 окт. 2020 г., в 12:34, Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > > >> написал(а): > > > >>> > > > >>> Hello! > > > >>> > > > >>> -1 from me for now. > > > >>> > > > >>> "Since Spring Data integration is actively used (compared to most > > > >> others), > > > >>> I would argue that it should only moved to extensions last, when > this > > > >>> process is debugged thoroughly and when we have at least one > > > "essentials > > > >> + > > > >>> extensions" release shipped with feedback. > > > >>> > > > >>> I think such release would be 2.9, so I think we should only move > > > Spring > > > >>> Data to extensions after 2.9 is released and feedback from this > > release > > > >> is > > > >>> processed." > > > >>> > > > >>> Regards, > > > >>> -- > > > >>> Ilya Kasnacheev > > > >>> > > > >>> > > > >>> пт, 9 окт. 2020 г. в 12:10, Nikolay Izhikov : > > > >>> > > > +1. > > > > > > Saikat, can you, please, take a look? > > > > > > > 9 окт. 2020 г., в 11:54, Nikita Amelchev > > > написал(а): > > > > > > > > Mikhail, > > > > > > > > +1 for migrate > > > > > > > > чт, 8 окт. 2020 г. в 18:34, Mikhail Petrov < > pmgheap@gmail.com > > >: > > > >> > > > >> Igniters, > > > >> > > > >> I propose to migrate spring-data modules from ignite main > > repository > > > >> to > > > >> ignite-extensions. > > > >> > > > >> > > > >> Are there any objections? > > > >> > > > >> > > > >> I've created ticket [1] and PR to both ignite [2] and > > > >> ignite-extensions > > > >> [3] repositories. > > > >> > > > >> > > > >> [1] - https://issues.apache.org/jira/browse/IGNITE-13559 > > > >> > > > >> [2] - https://github.com/apache/ignite/pull/8334 > > > >> > > > >> [3] - https://github.com/apache/ignite-extensions/pull/25 > > > >> > > > > > > > > > > > > -- > > > > Best wishes, > > > > Amelchev Nikita > > >
[MTCGA]: new failures in builds [5651661] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New Critical Failure in master-nightly Disk Page Compressions https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_DiskPageCompressions?branch=%3Cdefault%3E No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 00:11:19 10-10-2020
Re: Instance of IgniteClient in Multi threaded application
It's preferable to use a single client connection. The clients are multi-threaded, if I'm not mistaken. Btw, what type of the client you use (.NET, Java, ...)? - Denis On Fri, Oct 9, 2020 at 7:53 AM midulaj wrote: > Hi Igniters, > > If we are using ignite in a web service,can we reuse single IgniteClient > for > all requests or we have to create IgniteClient for each requests?? > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]
Nikolay,
re: the minor improvements. I'm not against of including those if we can
prepare the docs before the vote starts. Presently, the docs are "frozen"
for the 2.9 release, but I can scratch some time and take part in the docs
review the next week.
-
Denis
On Fri, Oct 9, 2020 at 12:40 AM Nikolay Izhikov wrote:
> Hello, Igniters.
>
> I prepared a patch [1] for blocker ticket [2] - «Server node fail and
> stops in case wrong datatype put in indexed field»
> Can someone, please, help me with the review?
>
> [1] https://github.com/apache/ignite/pull/8330
> [2] https://issues.apache.org/jira/browse/IGNITE-13553
>
> ==
>
> I propose to include several minor tickets to the scope of the 2.9 that
> increase Ignite User Experience
>
> 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.
>
> > 9 окт. 2020 г., в 04:04, Denis Magda написал(а):
> >
> > @Alex Plehanov ,
> >
> > If it still makes sense and not too late, you can cherry-pick the commit
> > with the new docs into the 2.9 branch:
> >
> https://github.com/apache/ignite/commit/073488ac97517bbaad9f6b94b781fc404646f191
> >
> > Anyway, it's not crucial as long as we agreed to make an exception for
> this
> > release. The docs were already published to the website and assembled
> from
> > the master. Once the vote passes, I'll make them visible and traceable
> from
> > the website menus.
> >
> > -
> > Denis
> >
> >
> > On Tue, Oct 6, 2020 at 7:20 AM Alexey Goncharuk <
> alexey.goncha...@gmail.com>
> > wrote:
> >
> >> Saikat,
> >>
> >> The plan sounds good to me! Do you have an idea for the timeline of the
> >> module releases? Let me know if I can help in any way.
> >>
> >> Also, I was looking into the modularization IEP and noticed that OSGI
> >> module is discussed to be moved to the extensions, but there is no
> >> corresponding ticket. Should I create one? I will be happy to help with
> >> moving this module to extensions.
> >>
> >> вт, 29 сент. 2020 г. в 03:03, Saikat Maitra :
> >>
> >>> Hi Alexey,
> >>>
> >>> All the modules as planned in IEP-36
> >>>
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36:+Modularization
> >>> are migrated to ignite-extensions repository.
> >>>
> >>> We can definitely plan to release ignite-extensions modules.
> >>>
> >>> I have a pending PR related to the kafka module and the PR is in review
> >>> https://github.com/apache/ignite/pull/8222 but its corresponding PR
> has
> >>> been merged in ignite-extensions repository.
> >>>
> >>> My thoughts / action items for the migration efforts and releases were
> >>> as follows:
> >>>
> >>> 1. Merge the changes for https://github.com/apache/ignite/pull/8222
> >>> 2. Fix the upload nightly packages task for ignite-core to help fix the
> >>> travis build failure in ignite-extensions repository.
> >>> 3. Review and update the README.md files for the ignite-extensions
> >> modules
> >>> as required.
> >>> 4. Update the docs for ignite-extensions modules in ignite-website.
> >>> 5. Release each module separately and share updates.
> >>>
> >>> Please let me know if you have feedback.
> >>>
> >>> Regards,
> >>> Saikat
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Sep 28, 2020 at 7:36 AM Petr Ivanov
> wrote:
> >>>
> It seems that gitbox.apache.org is not available on CI/CD.
>
> I will try to update VCS to GitHub.
>
>
>
>
>
> > On 28 Sep 2020, at 14:07, Alex Plehanov
> wrote:
> >
> > Guys,
> >
> > I've tried to build release candidate using TC [1]. But:
> > 1. I can't choose a branch in this TC task (there is no such field).
> > 2. On the "default" branch I got an error: Failed to collect changes,
> > error: List remote refs failed:
> > org.apache.http.conn.ConnectTimeoutException: Connect to
> > gitbox.apache.org:443 [gitbox.apache.org/52.202.80.70] failed:
> >> connect
> > timed out, VCS root: "GitBox [asf/ignite]" {instance id=300, parent
> > internal id=74, parent id=GitBoxAsfIgnite, description: "
> > https://gitbox.apache.org/repos/asf/ignite.git#refs/heads/master"}
> >
> > Is there some problem with this TC task? What am I doing wrong?
> >
> > [1] :
> >
>
> >>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Releases_ApacheIgniteMain_ReleaseBuild
> >
> > пн, 28 сент. 2020 г. в 13:15, Alexey Goncharuk <
> alexey.goncha...@gmail.com>:
> >
> >> Saikat, Nikolay,
> >>
> >> We have migrated a bunch of modules to ignite-extensions recently.
> Given
> >> that these modules will not be available in Ignite 2.9 anymore (will
> >> they?), should we also
Re: Migration of spring-data modules to ignite-extensions
How do we release all the modules that have already been moved to the extensions repository? https://github.com/apache/ignite-extensions/tree/master/modules For instance, when 2.9 comes out and the users start bumping up their Ignite versions in pom.xml, what should they set for Kafka, camel, etc. that are already in the extensions? 2.9 or..? - Denis On Fri, Oct 9, 2020 at 8:54 AM Ilya Kasnacheev wrote: > Hello! > > In any case, we need to release *something* and wait for it to be used by > actual users. > > Currently this is not happening since 2.8.1 contains all extensions as > modules. > > Regards, > -- > Ilya Kasnacheev > > > пт, 9 окт. 2020 г. в 15:12, Nikolay Izhikov : > > > Ilya. > > > > My understanding is the following - there is no such thing as «Ignite > > Extensions release» > > We can and should release each module separately. > > > > You can take as an example - spring-boot-autoconfigure extension release. > > I made it without releasing any other modules. > > > > This mean - we can release spring-data modules as frequently as we want. > > No correlation with the other extensions. > > > > > > > 9 окт. 2020 г., в 14:25, Ilya Kasnacheev > > написал(а): > > > > > > Hello! > > > > > > I mean the Apache Ignite 2.9 release and Ignite Extensions 1.0 release. > > > Once we get that in the wild and gather a few months of feedback (or > lack > > > thereof) then we can go on with it. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > пт, 9 окт. 2020 г. в 12:42, Nikolay Izhikov : > > > > > >> Ilya, we should move modules that is not related to Ignite core to > > >> extension. > > >> We shouldn’t support all possible integrations in the Ignite itself. > > >> > > >>> I would argue that it should only moved to extensions last, > > >>> when this process is debugged thoroughly and when we have at least > one > > >> "essentials + extensions" release shipped with feedback. > > >> > > >> Each extension should be released separately. > > >> What is «essentials + extensions» release do you have in mind? > > >> > > >> > > >> Moreover, ignite-spring-data release is not related to any Ignite > > releases. > > >> Why do we have to wait Ignite release to get spring-data fixes or > > updates? > > >> > > >>> 9 окт. 2020 г., в 12:34, Ilya Kasnacheev > > >> написал(а): > > >>> > > >>> Hello! > > >>> > > >>> -1 from me for now. > > >>> > > >>> "Since Spring Data integration is actively used (compared to most > > >> others), > > >>> I would argue that it should only moved to extensions last, when this > > >>> process is debugged thoroughly and when we have at least one > > "essentials > > >> + > > >>> extensions" release shipped with feedback. > > >>> > > >>> I think such release would be 2.9, so I think we should only move > > Spring > > >>> Data to extensions after 2.9 is released and feedback from this > release > > >> is > > >>> processed." > > >>> > > >>> Regards, > > >>> -- > > >>> Ilya Kasnacheev > > >>> > > >>> > > >>> пт, 9 окт. 2020 г. в 12:10, Nikolay Izhikov : > > >>> > > +1. > > > > Saikat, can you, please, take a look? > > > > > 9 окт. 2020 г., в 11:54, Nikita Amelchev > > написал(а): > > > > > > Mikhail, > > > > > > +1 for migrate > > > > > > чт, 8 окт. 2020 г. в 18:34, Mikhail Petrov >: > > >> > > >> Igniters, > > >> > > >> I propose to migrate spring-data modules from ignite main > repository > > >> to > > >> ignite-extensions. > > >> > > >> > > >> Are there any objections? > > >> > > >> > > >> I've created ticket [1] and PR to both ignite [2] and > > >> ignite-extensions > > >> [3] repositories. > > >> > > >> > > >> [1] - https://issues.apache.org/jira/browse/IGNITE-13559 > > >> > > >> [2] - https://github.com/apache/ignite/pull/8334 > > >> > > >> [3] - https://github.com/apache/ignite-extensions/pull/25 > > >> > > > > > > > > > -- > > > Best wishes, > > > Amelchev Nikita > > > > > > >> > > >> > > > > >
Re: Introduction
Bojidar, Sincerely I never used an approach with attaching patch files. It would be great if you can open PR. I suppose we should check with the Community whether a patch file approach is outdated and delete the section from the guide if it is. 2020-10-09 18:27 GMT+03:00, Bojidar Marinov : > Hey Ivan, > > According to the "How to contribute" document, submitting patch files is a > valid alternative to github pull requests, refs > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-2.CreateaPatch-file > . > If that information is outdated, I would happily open a pull request on > github instead. > > BRs, > Bojidar > > On Fri, Oct 9, 2020 at 6:20 PM Ivan Pavlukhin wrote: > >> Bojidar, >> >> While my knowledge can be outdated, but in my time it was required to >> create a pull request in GitHub and launch a TC bot check against that >> PR manually. >> >> 2020-10-09 18:08 GMT+03:00, Bojidar Marinov > >: >> > On Fri, Oct 9, 2020 at 5:15 PM Ivan Pavlukhin >> wrote: >> > >> >> Hi Bojidar, >> >> >> >> Welcome to the Apache Ignite Community! >> >> >> >> Thanks! >> > >> >> I added your account to a contributors list, now you can assign >> >> tickets to yourself. Am I getting it right that your contribution is >> >> in .NET part? >> >> >> >> Indeed, it is a contribution to Ignite.NET. >> > >> > Also it could be helpful to get familiar with a contribution process >> >> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute >> >> >> >> >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot >> >> >> >> Went over them again and tagged the issue as patch-available. >> >> Hopefully, >> > teamcity would pick it up soon. :) >> > >> >> >> >> 2020-10-08 23:08 GMT+03:00, Божидар Маринов < >> bojidar.marinov...@gmail.com >> >> >: >> >> > Hello Ignite Community! >> >> > >> >> > My name is Bojidar Marinov. I have used Apache Ignite for the past >> >> > few >> >> > months, and I would like to contribute to it starting with issue >> >> > IGNITE-13563, my JIRA username being bojidar-bg. >> >> > I have already submitted a patch, and reviews would be welcome. >> >> > >> >> > BRs, >> >> > Bojidar >> >> > >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> Ivan Pavlukhin >> >> >> > >> >> >> -- >> >> Best regards, >> Ivan Pavlukhin >> > -- Best regards, Ivan Pavlukhin
Re: Migration of spring-data modules to ignite-extensions
Hello! In any case, we need to release *something* and wait for it to be used by actual users. Currently this is not happening since 2.8.1 contains all extensions as modules. Regards, -- Ilya Kasnacheev пт, 9 окт. 2020 г. в 15:12, Nikolay Izhikov : > Ilya. > > My understanding is the following - there is no such thing as «Ignite > Extensions release» > We can and should release each module separately. > > You can take as an example - spring-boot-autoconfigure extension release. > I made it without releasing any other modules. > > This mean - we can release spring-data modules as frequently as we want. > No correlation with the other extensions. > > > > 9 окт. 2020 г., в 14:25, Ilya Kasnacheev > написал(а): > > > > Hello! > > > > I mean the Apache Ignite 2.9 release and Ignite Extensions 1.0 release. > > Once we get that in the wild and gather a few months of feedback (or lack > > thereof) then we can go on with it. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пт, 9 окт. 2020 г. в 12:42, Nikolay Izhikov : > > > >> Ilya, we should move modules that is not related to Ignite core to > >> extension. > >> We shouldn’t support all possible integrations in the Ignite itself. > >> > >>> I would argue that it should only moved to extensions last, > >>> when this process is debugged thoroughly and when we have at least one > >> "essentials + extensions" release shipped with feedback. > >> > >> Each extension should be released separately. > >> What is «essentials + extensions» release do you have in mind? > >> > >> > >> Moreover, ignite-spring-data release is not related to any Ignite > releases. > >> Why do we have to wait Ignite release to get spring-data fixes or > updates? > >> > >>> 9 окт. 2020 г., в 12:34, Ilya Kasnacheev > >> написал(а): > >>> > >>> Hello! > >>> > >>> -1 from me for now. > >>> > >>> "Since Spring Data integration is actively used (compared to most > >> others), > >>> I would argue that it should only moved to extensions last, when this > >>> process is debugged thoroughly and when we have at least one > "essentials > >> + > >>> extensions" release shipped with feedback. > >>> > >>> I think such release would be 2.9, so I think we should only move > Spring > >>> Data to extensions after 2.9 is released and feedback from this release > >> is > >>> processed." > >>> > >>> Regards, > >>> -- > >>> Ilya Kasnacheev > >>> > >>> > >>> пт, 9 окт. 2020 г. в 12:10, Nikolay Izhikov : > >>> > +1. > > Saikat, can you, please, take a look? > > > 9 окт. 2020 г., в 11:54, Nikita Amelchev > написал(а): > > > > Mikhail, > > > > +1 for migrate > > > > чт, 8 окт. 2020 г. в 18:34, Mikhail Petrov : > >> > >> Igniters, > >> > >> I propose to migrate spring-data modules from ignite main repository > >> to > >> ignite-extensions. > >> > >> > >> Are there any objections? > >> > >> > >> I've created ticket [1] and PR to both ignite [2] and > >> ignite-extensions > >> [3] repositories. > >> > >> > >> [1] - https://issues.apache.org/jira/browse/IGNITE-13559 > >> > >> [2] - https://github.com/apache/ignite/pull/8334 > >> > >> [3] - https://github.com/apache/ignite-extensions/pull/25 > >> > > > > > > -- > > Best wishes, > > Amelchev Nikita > > > >> > >> > >
Re: Introduction
Hey Ivan, According to the "How to contribute" document, submitting patch files is a valid alternative to github pull requests, refs https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-2.CreateaPatch-file . If that information is outdated, I would happily open a pull request on github instead. BRs, Bojidar On Fri, Oct 9, 2020 at 6:20 PM Ivan Pavlukhin wrote: > Bojidar, > > While my knowledge can be outdated, but in my time it was required to > create a pull request in GitHub and launch a TC bot check against that > PR manually. > > 2020-10-09 18:08 GMT+03:00, Bojidar Marinov >: > > On Fri, Oct 9, 2020 at 5:15 PM Ivan Pavlukhin > wrote: > > > >> Hi Bojidar, > >> > >> Welcome to the Apache Ignite Community! > >> > >> Thanks! > > > >> I added your account to a contributors list, now you can assign > >> tickets to yourself. Am I getting it right that your contribution is > >> in .NET part? > >> > >> Indeed, it is a contribution to Ignite.NET. > > > > Also it could be helpful to get familiar with a contribution process > >> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > >> > >> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot > >> > >> Went over them again and tagged the issue as patch-available. Hopefully, > > teamcity would pick it up soon. :) > > > >> > >> 2020-10-08 23:08 GMT+03:00, Божидар Маринов < > bojidar.marinov...@gmail.com > >> >: > >> > Hello Ignite Community! > >> > > >> > My name is Bojidar Marinov. I have used Apache Ignite for the past few > >> > months, and I would like to contribute to it starting with issue > >> > IGNITE-13563, my JIRA username being bojidar-bg. > >> > I have already submitted a patch, and reviews would be welcome. > >> > > >> > BRs, > >> > Bojidar > >> > > >> > >> > >> -- > >> > >> Best regards, > >> Ivan Pavlukhin > >> > > > > > -- > > Best regards, > Ivan Pavlukhin >
Re: Introduction
On Fri, Oct 9, 2020 at 5:15 PM Ivan Pavlukhin wrote: > Hi Bojidar, > > Welcome to the Apache Ignite Community! > > Thanks! > I added your account to a contributors list, now you can assign > tickets to yourself. Am I getting it right that your contribution is > in .NET part? > > Indeed, it is a contribution to Ignite.NET. Also it could be helpful to get familiar with a contribution process > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot > > Went over them again and tagged the issue as patch-available. Hopefully, teamcity would pick it up soon. :) > > 2020-10-08 23:08 GMT+03:00, Божидар Маринов >: > > Hello Ignite Community! > > > > My name is Bojidar Marinov. I have used Apache Ignite for the past few > > months, and I would like to contribute to it starting with issue > > IGNITE-13563, my JIRA username being bojidar-bg. > > I have already submitted a patch, and reviews would be welcome. > > > > BRs, > > Bojidar > > > > > -- > > Best regards, > Ivan Pavlukhin >
Instance of IgniteClient in Multi threaded application
Hi Igniters, If we are using ignite in a web service,can we reuse single IgniteClient for all requests or we have to create IgniteClient for each requests?? -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: Introduction
Hi Bojidar, Welcome to the Apache Ignite Community! I added your account to a contributors list, now you can assign tickets to yourself. Am I getting it right that your contribution is in .NET part? Also it could be helpful to get familiar with a contribution process https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot 2020-10-08 23:08 GMT+03:00, Божидар Маринов : > Hello Ignite Community! > > My name is Bojidar Marinov. I have used Apache Ignite for the past few > months, and I would like to contribute to it starting with issue > IGNITE-13563, my JIRA username being bojidar-bg. > I have already submitted a patch, and reviews would be welcome. > > BRs, > Bojidar > -- Best regards, Ivan Pavlukhin
Re: Migration of spring-data modules to ignite-extensions
+1 I said about it few months ago. пт, 9 окт. 2020 г., 15:13 Nikolay Izhikov : > Ilya. > > My understanding is the following - there is no such thing as «Ignite > Extensions release» > We can and should release each module separately. > > You can take as an example - spring-boot-autoconfigure extension release. > I made it without releasing any other modules. > > This mean - we can release spring-data modules as frequently as we want. > No correlation with the other extensions. > > > > 9 окт. 2020 г., в 14:25, Ilya Kasnacheev > написал(а): > > > > Hello! > > > > I mean the Apache Ignite 2.9 release and Ignite Extensions 1.0 release. > > Once we get that in the wild and gather a few months of feedback (or lack > > thereof) then we can go on with it. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пт, 9 окт. 2020 г. в 12:42, Nikolay Izhikov : > > > >> Ilya, we should move modules that is not related to Ignite core to > >> extension. > >> We shouldn’t support all possible integrations in the Ignite itself. > >> > >>> I would argue that it should only moved to extensions last, > >>> when this process is debugged thoroughly and when we have at least one > >> "essentials + extensions" release shipped with feedback. > >> > >> Each extension should be released separately. > >> What is «essentials + extensions» release do you have in mind? > >> > >> > >> Moreover, ignite-spring-data release is not related to any Ignite > releases. > >> Why do we have to wait Ignite release to get spring-data fixes or > updates? > >> > >>> 9 окт. 2020 г., в 12:34, Ilya Kasnacheev > >> написал(а): > >>> > >>> Hello! > >>> > >>> -1 from me for now. > >>> > >>> "Since Spring Data integration is actively used (compared to most > >> others), > >>> I would argue that it should only moved to extensions last, when this > >>> process is debugged thoroughly and when we have at least one > "essentials > >> + > >>> extensions" release shipped with feedback. > >>> > >>> I think such release would be 2.9, so I think we should only move > Spring > >>> Data to extensions after 2.9 is released and feedback from this release > >> is > >>> processed." > >>> > >>> Regards, > >>> -- > >>> Ilya Kasnacheev > >>> > >>> > >>> пт, 9 окт. 2020 г. в 12:10, Nikolay Izhikov : > >>> > +1. > > Saikat, can you, please, take a look? > > > 9 окт. 2020 г., в 11:54, Nikita Amelchev > написал(а): > > > > Mikhail, > > > > +1 for migrate > > > > чт, 8 окт. 2020 г. в 18:34, Mikhail Petrov : > >> > >> Igniters, > >> > >> I propose to migrate spring-data modules from ignite main repository > >> to > >> ignite-extensions. > >> > >> > >> Are there any objections? > >> > >> > >> I've created ticket [1] and PR to both ignite [2] and > >> ignite-extensions > >> [3] repositories. > >> > >> > >> [1] - https://issues.apache.org/jira/browse/IGNITE-13559 > >> > >> [2] - https://github.com/apache/ignite/pull/8334 > >> > >> [3] - https://github.com/apache/ignite-extensions/pull/25 > >> > > > > > > -- > > Best wishes, > > Amelchev Nikita > > > >> > >> > >
Re: IEP-53 Maintenance Mode: request for review
Hi Pavel, Thanks, I looked through your comments and fixed them. Could you please check one more time? On Fri, Oct 9, 2020 at 10:27 AM Pavel Tupitsyn wrote: > Hello Sergey, > > I went over the public API changes briefly and left some minor comments on > GitHub > > Thanks, > Pavel > > On Fri, Oct 9, 2020 at 9:59 AM Sergey Chugunov > wrote: > > > Hello Igniters, > > > > I'm getting closer to finishing main ticket for Maintenance Mode feature > > [1] and now working on test fixes (most likely test modifications are > > needed). > > > > So I would like to ask for a review of my pull request [2] to discuss the > > code earlier. Test status is pretty good so I expect to get a green visa > > soon. > > > > Could you please take a look? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13366 > > [2] https://github.com/apache/ignite/pull/8325 > > >
[jira] [Created] (IGNITE-13569) disable archiving + walCompactionEnabled probably broke reading from wal on server restart
Anton Kalashnikov created IGNITE-13569:
--
Summary: disable archiving + walCompactionEnabled probably broke
reading from wal on server restart
Key: IGNITE-13569
URL: https://issues.apache.org/jira/browse/IGNITE-13569
Project: Ignite
Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov
* Start cluster with 4 server node
* Preload
* Start 4 clients
* Start transactional loading
* Wait 10 sec
While loading:
For node in server nodes:
Kill -9 node
Wait 20 sec
Return node back
Wait 20 sec
Wal + Wal_archive - lab40, lab41 -
/storage/hdd/aromantsov/GG-18739
Looks like node can't read all wal files that was generated before start node
back
{noformat}
[12:50:27,001][SEVERE][wal-file-compressor-%null%-1-#71][FileWriteAheadLogManager]
Compression of WAL segment [idx=0] was skipped due to unexpected error
class org.apache.ignite.IgniteCheckedException: WAL archive segment is missing:
/storage/ssd/aromantsov/tiden/snapshots-190514-121520/test_pitr/node_1_1/.wal
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body0(FileWriteAheadLogManager.java:2076)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body(FileWriteAheadLogManager.java:2054)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
[12:50:27,001][SEVERE][wal-file-compressor-%null%-0-#69][FileWriteAheadLogManager]
Compression of WAL segment [idx=2] was skipped due to unexpected error
class org.apache.ignite.IgniteCheckedException: WAL archive segment is missing:
/storage/ssd/aromantsov/tiden/snapshots-190514-121520/test_pitr/node_1_1/0002.wal
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body0(FileWriteAheadLogManager.java:2076)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.access$4800(FileWriteAheadLogManager.java:2019)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.body(FileWriteAheadLogManager.java:1995)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
[12:50:27,001][SEVERE][wal-file-compressor-%null%-3-#73][FileWriteAheadLogManager]
Compression of WAL segment [idx=3] was skipped due to unexpected error
class org.apache.ignite.IgniteCheckedException: WAL archive segment is missing:
/storage/ssd/aromantsov/tiden/snapshots-190514-121520/test_pitr/node_1_1/0003.wal
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body0(FileWriteAheadLogManager.java:2076)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body(FileWriteAheadLogManager.java:2054)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
[12:50:27,001][SEVERE][wal-file-compressor-%null%-2-#72][FileWriteAheadLogManager]
Compression of WAL segment [idx=1] was skipped due to unexpected error
class org.apache.ignite.IgniteCheckedException: WAL archive segment is missing:
/storage/ssd/aromantsov/tiden/snapshots-190514-121520/test_pitr/node_1_1/0001.wal
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body0(FileWriteAheadLogManager.java:2076)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body(FileWriteAheadLogManager.java:2054)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
[12:50:27,002][SEVERE][wal-file-compressor-%null%-1-#71][FileWriteAheadLogManager]
Compression of WAL segment [idx=4] was skipped due to unexpected error
class org.apache.ignite.IgniteCheckedException: WAL archive segment is missing:
/storage/ssd/aromantsov/tiden/snapshots-190514-121520/test_pitr/node_1_1/0004.wal
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body0(FileWriteAheadLogManager.java:2076)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body(FileWriteAheadLogManager.java:2054)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
[12:50:27,002][SEVERE][wal-file-compressor-%null%-0-#69][FileWriteAheadLogManager]
Re: Migration of spring-data modules to ignite-extensions
Ilya. My understanding is the following - there is no such thing as «Ignite Extensions release» We can and should release each module separately. You can take as an example - spring-boot-autoconfigure extension release. I made it without releasing any other modules. This mean - we can release spring-data modules as frequently as we want. No correlation with the other extensions. > 9 окт. 2020 г., в 14:25, Ilya Kasnacheev > написал(а): > > Hello! > > I mean the Apache Ignite 2.9 release and Ignite Extensions 1.0 release. > Once we get that in the wild and gather a few months of feedback (or lack > thereof) then we can go on with it. > > Regards, > -- > Ilya Kasnacheev > > > пт, 9 окт. 2020 г. в 12:42, Nikolay Izhikov : > >> Ilya, we should move modules that is not related to Ignite core to >> extension. >> We shouldn’t support all possible integrations in the Ignite itself. >> >>> I would argue that it should only moved to extensions last, >>> when this process is debugged thoroughly and when we have at least one >> "essentials + extensions" release shipped with feedback. >> >> Each extension should be released separately. >> What is «essentials + extensions» release do you have in mind? >> >> >> Moreover, ignite-spring-data release is not related to any Ignite releases. >> Why do we have to wait Ignite release to get spring-data fixes or updates? >> >>> 9 окт. 2020 г., в 12:34, Ilya Kasnacheev >> написал(а): >>> >>> Hello! >>> >>> -1 from me for now. >>> >>> "Since Spring Data integration is actively used (compared to most >> others), >>> I would argue that it should only moved to extensions last, when this >>> process is debugged thoroughly and when we have at least one "essentials >> + >>> extensions" release shipped with feedback. >>> >>> I think such release would be 2.9, so I think we should only move Spring >>> Data to extensions after 2.9 is released and feedback from this release >> is >>> processed." >>> >>> Regards, >>> -- >>> Ilya Kasnacheev >>> >>> >>> пт, 9 окт. 2020 г. в 12:10, Nikolay Izhikov : >>> +1. Saikat, can you, please, take a look? > 9 окт. 2020 г., в 11:54, Nikita Amelchev написал(а): > > Mikhail, > > +1 for migrate > > чт, 8 окт. 2020 г. в 18:34, Mikhail Petrov : >> >> Igniters, >> >> I propose to migrate spring-data modules from ignite main repository >> to >> ignite-extensions. >> >> >> Are there any objections? >> >> >> I've created ticket [1] and PR to both ignite [2] and >> ignite-extensions >> [3] repositories. >> >> >> [1] - https://issues.apache.org/jira/browse/IGNITE-13559 >> >> [2] - https://github.com/apache/ignite/pull/8334 >> >> [3] - https://github.com/apache/ignite-extensions/pull/25 >> > > > -- > Best wishes, > Amelchev Nikita >> >>
Re: Migration of spring-data modules to ignite-extensions
Ilya, I haven't meant that removal of spring-data from Ignite main repository should be done before the 2.9 release and be included in it. Migration of spring-data to ignite-extensions could help us to make SpringData integration updates available for users earlier then the next Ignite release. For example adding support of thin client for SpringData. On 09.10.2020 14:25, Ilya Kasnacheev wrote: Hello! I mean the Apache Ignite 2.9 release and Ignite Extensions 1.0 release. Once we get that in the wild and gather a few months of feedback (or lack thereof) then we can go on with it. Regards,
[jira] [Created] (IGNITE-13568) Calcite integration. Decrease bounds of index scan
Yury Gerzhedovich created IGNITE-13568: -- Summary: Calcite integration. Decrease bounds of index scan Key: IGNITE-13568 URL: https://issues.apache.org/jira/browse/IGNITE-13568 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich As of now, we analyze just the first column from predicate to detemine lower and upper bounds for complex indexes. It decreasing search space, however for particular cases, it could be not so effective, for example, the selectivity of the first column is very low. We need to take into account all columns from predicate and suitable index. Need to keep in mind that each column at the index could be sorted in a different manner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Migration of spring-data modules to ignite-extensions
Hello! I mean the Apache Ignite 2.9 release and Ignite Extensions 1.0 release. Once we get that in the wild and gather a few months of feedback (or lack thereof) then we can go on with it. Regards, -- Ilya Kasnacheev пт, 9 окт. 2020 г. в 12:42, Nikolay Izhikov : > Ilya, we should move modules that is not related to Ignite core to > extension. > We shouldn’t support all possible integrations in the Ignite itself. > > > I would argue that it should only moved to extensions last, > > when this process is debugged thoroughly and when we have at least one > "essentials + extensions" release shipped with feedback. > > Each extension should be released separately. > What is «essentials + extensions» release do you have in mind? > > > Moreover, ignite-spring-data release is not related to any Ignite releases. > Why do we have to wait Ignite release to get spring-data fixes or updates? > > > 9 окт. 2020 г., в 12:34, Ilya Kasnacheev > написал(а): > > > > Hello! > > > > -1 from me for now. > > > > "Since Spring Data integration is actively used (compared to most > others), > > I would argue that it should only moved to extensions last, when this > > process is debugged thoroughly and when we have at least one "essentials > + > > extensions" release shipped with feedback. > > > > I think such release would be 2.9, so I think we should only move Spring > > Data to extensions after 2.9 is released and feedback from this release > is > > processed." > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пт, 9 окт. 2020 г. в 12:10, Nikolay Izhikov : > > > >> +1. > >> > >> Saikat, can you, please, take a look? > >> > >>> 9 окт. 2020 г., в 11:54, Nikita Amelchev > >> написал(а): > >>> > >>> Mikhail, > >>> > >>> +1 for migrate > >>> > >>> чт, 8 окт. 2020 г. в 18:34, Mikhail Petrov : > > Igniters, > > I propose to migrate spring-data modules from ignite main repository > to > ignite-extensions. > > > Are there any objections? > > > I've created ticket [1] and PR to both ignite [2] and > ignite-extensions > [3] repositories. > > > [1] - https://issues.apache.org/jira/browse/IGNITE-13559 > > [2] - https://github.com/apache/ignite/pull/8334 > > [3] - https://github.com/apache/ignite-extensions/pull/25 > > >>> > >>> > >>> -- > >>> Best wishes, > >>> Amelchev Nikita > >> > >> > >
[jira] [Created] (IGNITE-13567) TcpDiscoverySpi: incorrect value of the joiningNodeClient flag for the joining client
Amelchev Nikita created IGNITE-13567:
Summary: TcpDiscoverySpi: incorrect value of the joiningNodeClient
flag for the joining client
Key: IGNITE-13567
URL: https://issues.apache.org/jira/browse/IGNITE-13567
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
The TcpDiscoverySpi sets incorrect value of the {{joiningNodeClient}} flag for
the joining client:
- local client node on join gets {{false}}
- all nodes gets {{true}}
See {{DiscoverySpiDataExchange}} and {{DiscoveryDataBag#isJoiningNodeClient()}}.
In the ZookepeerSpi the flag is correct.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [MTCGA]: new failures in builds [5643882] needs to be handled
Denis, I would suggest to stay on a safe ground and associate an every commit with a ticket until we have a Community decision about relaxing this process for documentation tickets. As far as I remember sometimes as an exception we use a single ticket number for multiple commits (e.g. fix licenses broken in a main commit). 2020-10-09 4:00 GMT+03:00, Denis Magda : > Folks, > > Apologize for the disruption. The message didn't appear in my inbox even > when you CC-ed me directly. I was notified about the issue only today. > > Anyway, the licensing issue is fixed and the commit is back to the master. > > Speaking of the process, it can't be 100% the same for tech docs > contributions. For instance, it doesn't make sense to create a ticket for > every minor change a tech writer (who is already a committer) is about to > fix. We usually come across typos, unclear places that can be improved > right away, and requesting to create a JIRA ticket for such minor > improvements is overkill and counter-productive. Thus, you shouldn't expect > to see a JIRA ticket number in the commit log of every commit. Instead, we > need to come up with an additional prefix for those doc changes that don't > have tickets. I'll start a separate discussion for all these matters once > finish preparing the "How to Contribute" guide for the docs that is still > due. > > - > Denis > > > On Thu, Oct 8, 2020 at 2:19 AM Alexey Goncharuk > > wrote: > >> Denis, >> >> I've tried to quickly add licenses to the files, but there are simply too >> many different file types in the change. I reverted the original commit >> and >> the dependent one about the continuous query guarantees (which, btw, was >> merged without ticket name and with a merge commit). >> >> Please make sure to run the TC sanity check suites before merging it >> again. >> >> вт, 6 окт. 2020 г. в 13:07, Alexey Zinoviev : >> >> > Wow, I've got a >> > >> > Files with unapproved licenses: >> > >> > docs/_config.yml >> > docs/_plugins/asciidoctor-extensions.rb >> > docs/_includes/right-nav.html >> > docs/_includes/left-nav.html >> > docs/_includes/header.html >> > docs/_includes/toc.html >> > docs/_includes/section-toc.html >> > docs/_includes/copyright.html >> > docs/_includes/footer.html >> > docs/assets/js/page-nav.js >> > docs/assets/js/code-tabs.js >> > docs/assets/js/top-navigation.js >> > docs/assets/js/docs-menu.js >> > docs/assets/js/code-copy-to-clipboard.js >> > docs/assets/js/jquery.swiftype.autocomplete.js >> > docs/assets/js/index.js >> > docs/assets/js/anchor.min.js >> > docs/assets/css/styles.scss >> > docs/assets/css/docs.scss >> > docs/assets/css/asciidoc-pygments.css >> > docs/assets/images/github-gray.svg >> > docs/assets/images/left-nav-arrow.svg >> > docs/assets/images/lines-bg-3.svg >> > docs/assets/images/checkmark-green.svg >> > docs/assets/images/apple-blob.svg >> > docs/assets/images/feature-fast.svg >> > docs/assets/images/search.svg >> > docs/assets/images/glowing-box.svg >> > docs/assets/images/scala.svg >> > docs/assets/images/violent-blob.svg >> > docs/assets/images/feature-easy-installation.svg >> > docs/assets/images/edition-ue.svg >> > docs/assets/images/arrow-down.svg >> > docs/assets/images/lines-bg-4.svg >> > docs/assets/images/cpp.svg >> > docs/assets/images/arrow-down-white.svg >> > docs/assets/images/menu-icon.svg >> > docs/assets/images/copy-icon.svg >> > docs/assets/images/background-lines.svg >> > docs/assets/images/integrations/hibernate.svg >> > docs/assets/images/integrations/osgi.svg >> > docs/assets/images/integrations/oracle.svg >> > docs/assets/images/integrations/kafka.svg >> > docs/assets/images/integrations/spark.svg >> > docs/assets/images/integrations/more.svg >> > docs/assets/images/integrations/spring.svg >> > docs/assets/images/lines-bg-2.svg >> > docs/assets/images/java.svg >> > docs/assets/images/watermelon-blob.svg >> > docs/assets/images/edition-ee.svg >> > docs/assets/images/piece-of-paper-with-folded-top-right-corner.svg >> > docs/assets/images/feature-reliable.svg >> > docs/assets/images/lines-bg-1.svg >> > docs/assets/images/dotnet.svg >> > docs/assets/images/events-nav-arrow.svg >> > docs/assets/images/mousepad-blob.svg >> > docs/assets/images/github-white.svg >> > docs/assets/images/cancel.svg >> > docs/assets/images/edition-ce.svg >> > docs/run.sh >> > docs/_sass/left-nav.scss >> > docs/_sass/variables.scss >> > docs/_sass/text.scss >> > docs/_sass/layout.scss >> > docs/_sass/right-nav.scss >> > docs/_sass/header.scss >> > docs/_sass/rouge-base16-solarized.scss >> > docs/_sass/github.scss >> > docs/_sass/docs.scss >> > docs/_sass/callouts.scss >> > docs/_sass/code.scss >> > docs/_sass/footer.scss >> > docs/README.adoc >> > docs/_data/toc.yaml >> > docs/Gemfile >> > docs/_docs/messaging.adoc >> > docs/_docs/understanding-configuration.adoc >> >
Re: Migration of spring-data modules to ignite-extensions
+1 And, as a matter of fact, I think that spring data integration should be in spring-projects organization, just like spring-data-neo4j, spring-data-mongodb and the others. This way we will always have spring-data integration working correctly with the latest version of spring-data. 09.10.2020, 12:42, "Nikolay Izhikov" : > Ilya, we should move modules that is not related to Ignite core to extension. > We shouldn’t support all possible integrations in the Ignite itself. > >> I would argue that it should only moved to extensions last, >> when this process is debugged thoroughly and when we have at least one >> "essentials + extensions" release shipped with feedback. > > Each extension should be released separately. > What is «essentials + extensions» release do you have in mind? > > Moreover, ignite-spring-data release is not related to any Ignite releases. > Why do we have to wait Ignite release to get spring-data fixes or updates? > >> 9 окт. 2020 г., в 12:34, Ilya Kasnacheev >> написал(а): >> >> Hello! >> >> -1 from me for now. >> >> "Since Spring Data integration is actively used (compared to most others), >> I would argue that it should only moved to extensions last, when this >> process is debugged thoroughly and when we have at least one "essentials + >> extensions" release shipped with feedback. >> >> I think such release would be 2.9, so I think we should only move Spring >> Data to extensions after 2.9 is released and feedback from this release is >> processed." >> >> Regards, >> -- >> Ilya Kasnacheev >> >> пт, 9 окт. 2020 г. в 12:10, Nikolay Izhikov : >> >>> +1. >>> >>> Saikat, can you, please, take a look? >>> 9 окт. 2020 г., в 11:54, Nikita Amelchev >>> написал(а): Mikhail, +1 for migrate чт, 8 окт. 2020 г. в 18:34, Mikhail Petrov : > Igniters, > > I propose to migrate spring-data modules from ignite main repository to > ignite-extensions. > > Are there any objections? > > I've created ticket [1] and PR to both ignite [2] and ignite-extensions > [3] repositories. > > [1] - https://issues.apache.org/jira/browse/IGNITE-13559 > > [2] - https://github.com/apache/ignite/pull/8334 > > [3] - https://github.com/apache/ignite-extensions/pull/25 -- Best wishes, Amelchev Nikita
ignite-extenisions naming policy
Hi, Igniters. While working with ignite-extensions, I've faced some mismatch with naming of tag for extension: Artifact is 'ignite-spring-boot-autoconfigure-ext' Module is 'spring-boot-autoconfigure-ext' But tag is 'ignite-spring-boot-1.0.0' Can we: 1. match tag name with either module artifactID or maven name? 2. replace current ignite-spring-boot-1.0.0 with the or add new correct one?
[jira] [Created] (IGNITE-13566) Calcite integration. Table size statistics for cost planer
Yury Gerzhedovich created IGNITE-13566: -- Summary: Calcite integration. Table size statistics for cost planer Key: IGNITE-13566 URL: https://issues.apache.org/jira/browse/IGNITE-13566 Project: Ignite Issue Type: New Feature Components: sql Reporter: Yury Gerzhedovich Calcite planner doesn't know about the size of the tables and could make the wrong decision about join order. Need to add such knowledge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Migration of spring-data modules to ignite-extensions
Ilya, we should move modules that is not related to Ignite core to extension. We shouldn’t support all possible integrations in the Ignite itself. > I would argue that it should only moved to extensions last, > when this process is debugged thoroughly and when we have at least one > "essentials + extensions" release shipped with feedback. Each extension should be released separately. What is «essentials + extensions» release do you have in mind? Moreover, ignite-spring-data release is not related to any Ignite releases. Why do we have to wait Ignite release to get spring-data fixes or updates? > 9 окт. 2020 г., в 12:34, Ilya Kasnacheev > написал(а): > > Hello! > > -1 from me for now. > > "Since Spring Data integration is actively used (compared to most others), > I would argue that it should only moved to extensions last, when this > process is debugged thoroughly and when we have at least one "essentials + > extensions" release shipped with feedback. > > I think such release would be 2.9, so I think we should only move Spring > Data to extensions after 2.9 is released and feedback from this release is > processed." > > Regards, > -- > Ilya Kasnacheev > > > пт, 9 окт. 2020 г. в 12:10, Nikolay Izhikov : > >> +1. >> >> Saikat, can you, please, take a look? >> >>> 9 окт. 2020 г., в 11:54, Nikita Amelchev >> написал(а): >>> >>> Mikhail, >>> >>> +1 for migrate >>> >>> чт, 8 окт. 2020 г. в 18:34, Mikhail Petrov : Igniters, I propose to migrate spring-data modules from ignite main repository to ignite-extensions. Are there any objections? I've created ticket [1] and PR to both ignite [2] and ignite-extensions [3] repositories. [1] - https://issues.apache.org/jira/browse/IGNITE-13559 [2] - https://github.com/apache/ignite/pull/8334 [3] - https://github.com/apache/ignite-extensions/pull/25 >>> >>> >>> -- >>> Best wishes, >>> Amelchev Nikita >> >>
Re: Migration of spring-data modules to ignite-extensions
Hello! -1 from me for now. "Since Spring Data integration is actively used (compared to most others), I would argue that it should only moved to extensions last, when this process is debugged thoroughly and when we have at least one "essentials + extensions" release shipped with feedback. I think such release would be 2.9, so I think we should only move Spring Data to extensions after 2.9 is released and feedback from this release is processed." Regards, -- Ilya Kasnacheev пт, 9 окт. 2020 г. в 12:10, Nikolay Izhikov : > +1. > > Saikat, can you, please, take a look? > > > 9 окт. 2020 г., в 11:54, Nikita Amelchev > написал(а): > > > > Mikhail, > > > > +1 for migrate > > > > чт, 8 окт. 2020 г. в 18:34, Mikhail Petrov : > >> > >> Igniters, > >> > >> I propose to migrate spring-data modules from ignite main repository to > >> ignite-extensions. > >> > >> > >> Are there any objections? > >> > >> > >> I've created ticket [1] and PR to both ignite [2] and ignite-extensions > >> [3] repositories. > >> > >> > >> [1] - https://issues.apache.org/jira/browse/IGNITE-13559 > >> > >> [2] - https://github.com/apache/ignite/pull/8334 > >> > >> [3] - https://github.com/apache/ignite-extensions/pull/25 > >> > > > > > > -- > > Best wishes, > > Amelchev Nikita > >
Re: Migration of spring-data modules to ignite-extensions
+1. Saikat, can you, please, take a look? > 9 окт. 2020 г., в 11:54, Nikita Amelchev написал(а): > > Mikhail, > > +1 for migrate > > чт, 8 окт. 2020 г. в 18:34, Mikhail Petrov : >> >> Igniters, >> >> I propose to migrate spring-data modules from ignite main repository to >> ignite-extensions. >> >> >> Are there any objections? >> >> >> I've created ticket [1] and PR to both ignite [2] and ignite-extensions >> [3] repositories. >> >> >> [1] - https://issues.apache.org/jira/browse/IGNITE-13559 >> >> [2] - https://github.com/apache/ignite/pull/8334 >> >> [3] - https://github.com/apache/ignite-extensions/pull/25 >> > > > -- > Best wishes, > Amelchev Nikita
Re[2]: Broken test in master: BasicIndexTest
Of course, i still have no ticket filled. As was discussed in private i will fill other ticket that can lead to potential problems. >Hi everyone, > >I believe I have a fix for this bug - >https://issues.apache.org/jira/browse/IGNITE-13500, So Zhenya you can leave >this problem to me. > >-- >Best regards, >Anton Kalashnikov > > > >09.10.2020, 10:19, "Sergey Chugunov" < sergey.chugu...@gmail.com >: >> Max, >> >> Thanks for spotting this, great catch! >> >> Zhenya, could you please file a ticket of at least Critical priority? >> >> On Fri, Oct 9, 2020 at 9:24 AM Zhenya Stanilovsky >> < arzamas...@mail.ru.invalid > wrote: >> >>> Thanks Maxim, the test is correct no need for removal. >>> I checked 2.9 too, but looks it all ok there. I will take a look. >>> >Hi, Igniters! >>> > >>> >I was discovering how indexes work and found a failed test. >>> >BasicIndexTest#testInlineSizeChange is broken in master and it's not a >>> >flaky case [1]. But it has been failing since 25/09 only. >>> > >>> >I discovered that it happened after the IGNITE-13207 ticket merged >>> >(Checkpointer code refactoring) [2]. I'm not sure about the expected >>> >behaviour of the inline index and how checkpointer affects it. But let's >>> >fix it if it is a bug or completely remove this test. >>> > >>> >[1] >>> > >>> >>> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6131871779633595667=%3Cdefault%3E=testDetails >>> > >>> >[2] https://issues.apache.org/jira/browse/IGNITE-13207 >>> >
[jira] [Created] (IGNITE-13564) Improve SYSTEM_WORKER_BLOCKED reporting.
Ivan Daschinskiy created IGNITE-13564:
-
Summary: Improve SYSTEM_WORKER_BLOCKED reporting.
Key: IGNITE-13564
URL: https://issues.apache.org/jira/browse/IGNITE-13564
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.8.1, 2.9
Reporter: Ivan Daschinskiy
Assignee: Ivan Daschinskiy
Fix For: 2.10
Currently, reporting of system thread blocking has major drawbacks.
1. As system worker blocking is detected by another thread, due to
implementation, failure handler receives not full information about problem. In
{{FailureContext}} we have only two fields -- {{type}} and {{err}}. Throwable
{{err}} is generated in thread-detector flow, so we lost a context of main
problem.
2. Currently, due to implementation, we print not full stacktrace of blocking
thread in {{org.apache.ignite.internal.worker.WorkersRegistry#onIdle}}.
3. Current approach doesn't work when there is one thread in registry, this
fact isn't checked and this can cause to infinite looping of single thread,
calling {{onIdle}}
This two drawbacks can lead to completely loss of information about blocking
system thread.
I suggests:
1. Add another parameter in {{FailureContext}}, namely {{worker}}
2. Fix threaddump printing.
3. Add assertion when there is only one system thread in registry
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Migration of spring-data modules to ignite-extensions
Mikhail, +1 for migrate чт, 8 окт. 2020 г. в 18:34, Mikhail Petrov : > > Igniters, > > I propose to migrate spring-data modules from ignite main repository to > ignite-extensions. > > > Are there any objections? > > > I've created ticket [1] and PR to both ignite [2] and ignite-extensions > [3] repositories. > > > [1] - https://issues.apache.org/jira/browse/IGNITE-13559 > > [2] - https://github.com/apache/ignite/pull/8334 > > [3] - https://github.com/apache/ignite-extensions/pull/25 > -- Best wishes, Amelchev Nikita
Re: Broken test in master: BasicIndexTest
Hi everyone, I believe I have a fix for this bug - https://issues.apache.org/jira/browse/IGNITE-13500, So Zhenya you can leave this problem to me. -- Best regards, Anton Kalashnikov 09.10.2020, 10:19, "Sergey Chugunov" : > Max, > > Thanks for spotting this, great catch! > > Zhenya, could you please file a ticket of at least Critical priority? > > On Fri, Oct 9, 2020 at 9:24 AM Zhenya Stanilovsky > wrote: > >> Thanks Maxim, the test is correct no need for removal. >> I checked 2.9 too, but looks it all ok there. I will take a look. >> >Hi, Igniters! >> > >> >I was discovering how indexes work and found a failed test. >> >BasicIndexTest#testInlineSizeChange is broken in master and it's not a >> >flaky case [1]. But it has been failing since 25/09 only. >> > >> >I discovered that it happened after the IGNITE-13207 ticket merged >> >(Checkpointer code refactoring) [2]. I'm not sure about the expected >> >behaviour of the inline index and how checkpointer affects it. But let's >> >fix it if it is a bug or completely remove this test. >> > >> >[1] >> > >> >> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6131871779633595667=%3Cdefault%3E=testDetails >> > >> >[2] https://issues.apache.org/jira/browse/IGNITE-13207 >> >
Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]
Hello, Igniters.
I prepared a patch [1] for blocker ticket [2] - «Server node fail and stops in
case wrong datatype put in indexed field»
Can someone, please, help me with the review?
[1] https://github.com/apache/ignite/pull/8330
[2] https://issues.apache.org/jira/browse/IGNITE-13553
==
I propose to include several minor tickets to the scope of the 2.9 that
increase Ignite User Experience
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.
> 9 окт. 2020 г., в 04:04, Denis Magda написал(а):
>
> @Alex Plehanov ,
>
> If it still makes sense and not too late, you can cherry-pick the commit
> with the new docs into the 2.9 branch:
> https://github.com/apache/ignite/commit/073488ac97517bbaad9f6b94b781fc404646f191
>
> Anyway, it's not crucial as long as we agreed to make an exception for this
> release. The docs were already published to the website and assembled from
> the master. Once the vote passes, I'll make them visible and traceable from
> the website menus.
>
> -
> Denis
>
>
> On Tue, Oct 6, 2020 at 7:20 AM Alexey Goncharuk
> wrote:
>
>> Saikat,
>>
>> The plan sounds good to me! Do you have an idea for the timeline of the
>> module releases? Let me know if I can help in any way.
>>
>> Also, I was looking into the modularization IEP and noticed that OSGI
>> module is discussed to be moved to the extensions, but there is no
>> corresponding ticket. Should I create one? I will be happy to help with
>> moving this module to extensions.
>>
>> вт, 29 сент. 2020 г. в 03:03, Saikat Maitra :
>>
>>> Hi Alexey,
>>>
>>> All the modules as planned in IEP-36
>>>
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36:+Modularization
>>> are migrated to ignite-extensions repository.
>>>
>>> We can definitely plan to release ignite-extensions modules.
>>>
>>> I have a pending PR related to the kafka module and the PR is in review
>>> https://github.com/apache/ignite/pull/8222 but its corresponding PR has
>>> been merged in ignite-extensions repository.
>>>
>>> My thoughts / action items for the migration efforts and releases were
>>> as follows:
>>>
>>> 1. Merge the changes for https://github.com/apache/ignite/pull/8222
>>> 2. Fix the upload nightly packages task for ignite-core to help fix the
>>> travis build failure in ignite-extensions repository.
>>> 3. Review and update the README.md files for the ignite-extensions
>> modules
>>> as required.
>>> 4. Update the docs for ignite-extensions modules in ignite-website.
>>> 5. Release each module separately and share updates.
>>>
>>> Please let me know if you have feedback.
>>>
>>> Regards,
>>> Saikat
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Sep 28, 2020 at 7:36 AM Petr Ivanov wrote:
>>>
It seems that gitbox.apache.org is not available on CI/CD.
I will try to update VCS to GitHub.
> On 28 Sep 2020, at 14:07, Alex Plehanov
wrote:
>
> Guys,
>
> I've tried to build release candidate using TC [1]. But:
> 1. I can't choose a branch in this TC task (there is no such field).
> 2. On the "default" branch I got an error: Failed to collect changes,
> error: List remote refs failed:
> org.apache.http.conn.ConnectTimeoutException: Connect to
> gitbox.apache.org:443 [gitbox.apache.org/52.202.80.70] failed:
>> connect
> timed out, VCS root: "GitBox [asf/ignite]" {instance id=300, parent
> internal id=74, parent id=GitBoxAsfIgnite, description: "
> https://gitbox.apache.org/repos/asf/ignite.git#refs/heads/master"}
>
> Is there some problem with this TC task? What am I doing wrong?
>
> [1] :
>
>> https://ci.ignite.apache.org/viewType.html?buildTypeId=Releases_ApacheIgniteMain_ReleaseBuild
>
> пн, 28 сент. 2020 г. в 13:15, Alexey Goncharuk <
alexey.goncha...@gmail.com>:
>
>> Saikat, Nikolay,
>>
>> We have migrated a bunch of modules to ignite-extensions recently.
Given
>> that these modules will not be available in Ignite 2.9 anymore (will
>> they?), should we also plan to release the extensions?
>>
>> ср, 23 сент. 2020 г. в 21:49, Alex Plehanov >> :
>>
>>> Igniters,
>>>
>>> I've prepared release notes for the 2.9 release [1]. Can anyone
>> review
>> it,
>>> please?
>>>
>>> [1]: https://github.com/apache/ignite/pull/8273
>>>
>>> вт, 22 сент. 2020 г. в 09:39, Alex Plehanov <
>> plehanov.a...@gmail.com
> :
>>>
Guys,
I've filled the ticket with reproducer [1] for the discovery bug.
This
>>> bug
caused by [2] ticket. We discussed with
Re: IEP-53 Maintenance Mode: request for review
Hello Sergey, I went over the public API changes briefly and left some minor comments on GitHub Thanks, Pavel On Fri, Oct 9, 2020 at 9:59 AM Sergey Chugunov wrote: > Hello Igniters, > > I'm getting closer to finishing main ticket for Maintenance Mode feature > [1] and now working on test fixes (most likely test modifications are > needed). > > So I would like to ask for a review of my pull request [2] to discuss the > code earlier. Test status is pretty good so I expect to get a green visa > soon. > > Could you please take a look? > > [1] https://issues.apache.org/jira/browse/IGNITE-13366 > [2] https://github.com/apache/ignite/pull/8325 >
Re: Broken test in master: BasicIndexTest
Max, Thanks for spotting this, great catch! Zhenya, could you please file a ticket of at least Critical priority? On Fri, Oct 9, 2020 at 9:24 AM Zhenya Stanilovsky wrote: > > > Thanks Maxim, the test is correct no need for removal. > I checked 2.9 too, but looks it all ok there. I will take a look. > >Hi, Igniters! > > > >I was discovering how indexes work and found a failed test. > >BasicIndexTest#testInlineSizeChange is broken in master and it's not a > >flaky case [1]. But it has been failing since 25/09 only. > > > >I discovered that it happened after the IGNITE-13207 ticket merged > >(Checkpointer code refactoring) [2]. I'm not sure about the expected > >behaviour of the inline index and how checkpointer affects it. But let's > >fix it if it is a bug or completely remove this test. > > > >[1] > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6131871779633595667=%3Cdefault%3E=testDetails > > > >[2] https://issues.apache.org/jira/browse/IGNITE-13207 > > >
IEP-53 Maintenance Mode: request for review
Hello Igniters, I'm getting closer to finishing main ticket for Maintenance Mode feature [1] and now working on test fixes (most likely test modifications are needed). So I would like to ask for a review of my pull request [2] to discuss the code earlier. Test status is pretty good so I expect to get a green visa soon. Could you please take a look? [1] https://issues.apache.org/jira/browse/IGNITE-13366 [2] https://github.com/apache/ignite/pull/8325
Re: Broken test in master: BasicIndexTest
Thanks Maxim, the test is correct no need for removal. I checked 2.9 too, but looks it all ok there. I will take a look. >Hi, Igniters! > >I was discovering how indexes work and found a failed test. >BasicIndexTest#testInlineSizeChange is broken in master and it's not a >flaky case [1]. But it has been failing since 25/09 only. > >I discovered that it happened after the IGNITE-13207 ticket merged >(Checkpointer code refactoring) [2]. I'm not sure about the expected >behaviour of the inline index and how checkpointer affects it. But let's >fix it if it is a bug or completely remove this test. > >[1] >https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6131871779633595667=%3Cdefault%3E=testDetails > >[2] https://issues.apache.org/jira/browse/IGNITE-13207 >
