[MTCGA]: new failures in builds [5653845] needs to be handled

Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize

Re: ignite-extenisions naming policy

Thank you Alexey Regards, Saikat On Tue, Oct 13, 2020 at 6:38 AM Petr Ivanov wrote: > Thanks. Aleksey! > > > > On 13 Oct 2020, at 13:09, Alexey Goncharuk > wrote: > > > > Makes sense, > > > > I added a tag copy to match the released module name. > > > > вт, 13 окт. 2020 г. в 10:08, Petr Ivanov

Re: Ignite-extensions repository structure

Hi Alexey, Thank you for sharing your questions. 1. The extensions modules in master branch are pointing to SNAPSHOT version of ignite-core module so that we can test that master branch of extensions modules are compatible with master branch of SNAPSHOT version of ignite-core module. Our idea w

Re: Apache Ignite 3.0

Hi Yakov, Great to have you here! :) Thanks for the inputs. My comments are below. *Alexey*, could you please comment on the points 3 and 4? -Val On Sat, Oct 10, 2020 at 4:36 PM Yakov Zhdanov wrote: > Hi! > I am back! > > Here are several ideas on top of my mind for Ignite 3.0 > 1. Client nod

Re: [VOTE] Release Apache Ignite 2.9.0 RC3

+1 (binding) Started a two-node Ignite cluster using the binary package and the ignite.sh script. - Denis On Tue, Oct 13, 2020 at 7:18 AM Alex Plehanov wrote: > Dear Community, > > > I have uploaded a release candidate to: > https://dist.apache.org/repos/dist/dev/ignite/2.9.0-rc3/ > https://d

[jira] [Created] (IGNITE-13579) Calcite integration. Wrong distribution assertion in case of nested request execution.

Stanilovsky Evgeny created IGNITE-13579: --- Summary: Calcite integration. Wrong distribution assertion in case of nested request execution. Key: IGNITE-13579 URL: https://issues.apache.org/jira/browse/IGNITE-

[VOTE] Release Apache Ignite 2.9.0 RC3

Dear Community, I have uploaded a release candidate to: https://dist.apache.org/repos/dist/dev/ignite/2.9.0-rc3/ https://dist.apache.org/repos/dist/dev/ignite/packages_2.9.0-rc3/ The following staging can be used for testing: https://repository.apache.org/content/repositories/orgapacheignite-148

[jira] [Created] (IGNITE-13578) Update ignite-kafka dependencies to get rid of reported CVEs

Stepachev Maksim created IGNITE-13578: - Summary: Update ignite-kafka dependencies to get rid of reported CVEs Key: IGNITE-13578 URL: https://issues.apache.org/jira/browse/IGNITE-13578 Project: Ign

Re: ignite-extenisions naming policy

Thanks. Aleksey! > On 13 Oct 2020, at 13:09, Alexey Goncharuk wrote: > > Makes sense, > > I added a tag copy to match the released module name. > > вт, 13 окт. 2020 г. в 10:08, Petr Ivanov : > >> Keep it as a reference to what? >> That tag will be confusing both users and developers because:

Re: Ignite-extensions repository structure

Nikolay, > > I thought the extensions should be tested against the latest released > Ignite version > > It seems, we should try to keep extension Ignite version agnostic. > If it impossible, then yes, we should use latest Ignite version. > I doubt it's possible at least for OSGi: the published art

[jira] [Created] (IGNITE-13577) Add support to graceful shutdown for ZookeeperDiscoverySpi

Ivan Daschinskiy created IGNITE-13577: - Summary: Add support to graceful shutdown for ZookeeperDiscoverySpi Key: IGNITE-13577 URL: https://issues.apache.org/jira/browse/IGNITE-13577 Project: Ignite

Re: Ignite-extensions repository structure

Hello, Alexey. > Nikolay, for spring autoconfigure, did you do this manually or does maven > allow to granularly upgrade the modules' version? Manually. > I thought the extensions should be tested against the latest released Ignite > version It seems, we should try to keep extension Ignite

Ignite-extensions repository structure

Nikolay, Saikat, Igniters, I started migrating the OSGi modules to the ignite-extensions repository and I've got some questions regarding the ignite-extensions project: - We agreed that ignite extensions have their own release cycle, so why do we reference a -snapshot version of Ignite in t

Re: ignite-extenisions naming policy

Makes sense, I added a tag copy to match the released module name. вт, 13 окт. 2020 г. в 10:08, Petr Ivanov : > Keep it as a reference to what? > That tag will be confusing both users and developers because: > — there is no release of any extension with version 1.0, only 1.0.0 > — ignite-sprin

[jira] [Created] (IGNITE-13576) No help information for contol.sh --property help

Taras Ledkov created IGNITE-13576: - Summary: No help information for contol.sh --property help Key: IGNITE-13576 URL: https://issues.apache.org/jira/browse/IGNITE-13576 Project: Ignite Issue

Re: Instance of IgniteClient in Multi threaded application

Thanks Pavel, We will try that option. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: Instance of IgniteClient in Multi threaded application

Ok.Thanks Denis for your replay -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

Guys, I've cherry-picked IGNITE-12350, IGNITE-13376, IGNITE-13280, and documentation to 2.9. Denis, I see no benefits of a single vote for Ignite and extensions. I think it will postpone Ignite 2.9 release. If some user uses some extension, he still can continue to work with Ignite 2.8 release u

Re: ignite-extenisions naming policy

Keep it as a reference to what? That tag will be confusing both users and developers because: — there is no release of any extension with version 1.0, only 1.0.0 — ignite-spring-boot can mean autoconfigure, thin-client-autoconfigure, or both I think we should at least add new compliant tag to th