[jira] [Created] (IGNITE-13575) Invalid blocking section in GridNioWorker and GridNioClientWorker leads to false positive blocking thread detection

[Ivan Daschinskiy (Jira)]

Ivan Daschinskiy created IGNITE-13575:
-

 Summary: Invalid blocking section in GridNioWorker and 
GridNioClientWorker leads to false positive blocking thread detection
 Key: IGNITE-13575
 URL: https://issues.apache.org/jira/browse/IGNITE-13575
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8.1, 2.9
Reporter: Ivan Daschinskiy
Assignee: Ivan Daschinskiy


If {{IGNITE_SYSTEM_WORKER_BLOCKED_TIMEOUT}} less than 2000 ms, then simple 
{{epoll_wait}} for 2000 on idle cluster is considered as critical failure. 

We should surround {{selector.select}} with {{blockingSectionBegin}} and 
{{blockingSectionEnd}} instead of {{updateHeartbeat}}





--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[Denis Magda]

Is it possible/reasonable to run a single vote for Ignite 2.9 and all the
migrated extensions? This time. @Alex Plehanov ,
what do you think?

If we decide to release the versions 1.0.0 of the extensions after 2.9 is
out then it can last for a week or so...because we need to build, update
docs, vote, publish.

-
Denis


On Mon, Oct 12, 2020 at 7:19 PM Saikat Maitra 
wrote:

> Hi Denis,
>
> All the modules except OSGi have been migrated. Alexey is creating a
> separate ticket for OSGi and we can migrate the same as well.
>
> My thoughts are Apache Ignite 2.9.0 and migrated extensions 1.0.0 to be
> released together. I am thinking depending on the voting process and
> testing cycles we can release the extensions 1.0.0 together with Apache
> Ignite 2.9.0 or right after within days of Apache Ignite 2.9.0 release.
>
>
> Regards,
> Saikat
>
> On Mon, Oct 12, 2020 at 2:58 PM Denis Magda  wrote:
>
>> Saikat, Alex,
>>
>> Based on your inputs here, it sounds like once Ignite 2.9 gets released,
>> all the integrations that made their way to the extensions repo [1] will
>> get stuck in limbo for some time. What I mean here:
>>
>>1. While the users will be bumping up their ignite-core,
>>ignite-indexing, etc. versions to 2.9, they won't find a 2.9 artifact for
>>Kafka, Camel and other extensions
>>2. Also, the users won't find 1.0 versions of those extensions that
>>also need to be released
>>
>> So, it's unclear how those users are supposed to upgrade to Ignite 2.9 if
>> they use any of the extensions. Is it safe to use a 2.8 version of an
>> extension? Or, should we release the 1.0 versions of all the migrated
>> extensions together with 2.9?
>>
>>
>> [1] https://github.com/apache/ignite-extensions/tree/master/modules
>>
>>
>> -
>> 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 

Re: Ignite license checker rejects MIT-licensed files

[Denis Magda]

Instead of using the "addDefaultLicenseMatchers" setting, we developed a
practice of excluding non-Apache licenses from the checklist of the license
checker. A couple of examples:

   - BSD license:
   https://github.com/apache/ignite/blob/ignite-13574/parent/pom.xml#L889
   - Another BSD license:
   https://github.com/apache/ignite/blob/ignite-13574/parent/pom.xml#L984
   - JetBrains sources:
   https://github.com/apache/ignite/blob/ignite-13574/parent/pom.xml#L903
   - the list goes on and on, check all the exclusions of the license
   checker:
   https://github.com/apache/ignite/blob/ignite-13574/parent/pom.xml#L842

Have we ever tried to use the "addDefaultLicenseMatchers" setting instead?

-
Denis


On Mon, Oct 12, 2020 at 3:25 PM Denis Magda  wrote:

> Igniters,
>
> I was adding a missing license header to some sources that were included
> in our repository and found that the license checker rejects the MIT
> license (it's compliant with Apache 2.0
> ). Take these
> files as an example that are protected by the MIT license but rejected by
> the license checker:
>
>-
>
> https://github.com/apache/ignite/blob/ignite-13574/docs/_sass/rouge-base16-solarized.scss
>-
>
> https://github.com/apache/ignite/blob/ignite-13574/docs/_plugins/asciidoctor-extensions.rb
>
>
> All the checks pass if to set the "addDefaultLicenseMatchers" setting of
> the license checker to "true". Presently, that setting is "false":
> https://github.com/apache/ignite/blob/ignite-13574/parent/pom.xml#L806
>
> Does anybody know why the "addDefaultLicenseMatchers" parameter is set to
> "false"? I would go ahead and change it to "true".
>
> -
> Denis
>

Re: ignite-extenisions naming policy

[Saikat Maitra]

Hi Petr,

Since, we already released a version with the old tag I am thinking we can
keep it as reference and we can follow the new naming convention for git
tag from next release onwards.

Regards,
Saikat



On Mon, Oct 12, 2020 at 1:42 AM Petr Ivanov  wrote:

> Hi!
>
>
> Yes., the git tag.
>
> The naming is good. thanks.
> Can you also rename current one, please, or add new referring the old with
> agreed naming?
>
>
> > On 10 Oct 2020, at 07:25, Saikat Maitra  wrote:
> >
> > 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: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Saikat Maitra]

Hi Denis,

All the modules except OSGi have been migrated. Alexey is creating a
separate ticket for OSGi and we can migrate the same as well.

My thoughts are Apache Ignite 2.9.0 and migrated extensions 1.0.0 to be
released together. I am thinking depending on the voting process and
testing cycles we can release the extensions 1.0.0 together with Apache
Ignite 2.9.0 or right after within days of Apache Ignite 2.9.0 release.


Regards,
Saikat

On Mon, Oct 12, 2020 at 2:58 PM Denis Magda  wrote:

> Saikat, Alex,
>
> Based on your inputs here, it sounds like once Ignite 2.9 gets released,
> all the integrations that made their way to the extensions repo [1] will
> get stuck in limbo for some time. What I mean here:
>
>1. While the users will be bumping up their ignite-core,
>ignite-indexing, etc. versions to 2.9, they won't find a 2.9 artifact for
>Kafka, Camel and other extensions
>2. Also, the users won't find 1.0 versions of those extensions that
>also need to be released
>
> So, it's unclear how those users are supposed to upgrade to Ignite 2.9 if
> they use any of the extensions. Is it safe to use a 2.8 version of an
> extension? Or, should we release the 1.0 versions of all the migrated
> extensions together with 2.9?
>
>
> [1] https://github.com/apache/ignite-extensions/tree/master/modules
>
>
> -
> 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 plan to release the extensions?
>> >> >>
>> >> >> ср, 23 сент. 2020 г. в 21:49, Alex Plehanov <
>> plehanov.a...@gmail.com>:
>> >> >>
>> >> >>> 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
>> >> >:
>> >> >>>
>> >>  

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

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 *Test with high flaky rate in master 
BinaryMetadataRegistrationInsideEntryProcessorTest.testContinuousQueryAndBinaryObjectBuilder
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3578155817890825802=%3Cdefault%3E=testDetails
 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 01:56:20 13-10-2020 

Ignite license checker rejects MIT-licensed files

[Denis Magda]

Igniters,

I was adding a missing license header to some sources that were included in
our repository and found that the license checker rejects the MIT license (it's
compliant with Apache 2.0
). Take these files
as an example that are protected by the MIT license but rejected by the
license checker:

   -
   
https://github.com/apache/ignite/blob/ignite-13574/docs/_sass/rouge-base16-solarized.scss
   -
   
https://github.com/apache/ignite/blob/ignite-13574/docs/_plugins/asciidoctor-extensions.rb


All the checks pass if to set the "addDefaultLicenseMatchers" setting of
the license checker to "true". Presently, that setting is "false":
https://github.com/apache/ignite/blob/ignite-13574/parent/pom.xml#L806

Does anybody know why the "addDefaultLicenseMatchers" parameter is set to
"false"? I would go ahead and change it to "true".

-
Denis

[jira] [Created] (IGNITE-13574) Ignite Docs: clarify licenses for some imported files

[Denis A. Magda (Jira)]

Denis A. Magda created IGNITE-13574:
---

 Summary: Ignite Docs: clarify licenses for some imported files
 Key: IGNITE-13574
 URL: https://issues.apache.org/jira/browse/IGNITE-13574
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Denis A. Magda
Assignee: Denis A. Magda


There are several imported files that are used by our docs engine which 
licenses have to be mentioned in our repo:
* AsciiDoctor extension [1] is protected by MIT license [2].
* Some CSS styles [3] used by Jekyll are protected by MIT license [4].
* A JS lib for the deep linking of pages [5] is protected by MIT license [6]
* This JS library [7] is not used and can be removed.


[1] 
https://github.com/apache/ignite/blob/master/docs/_plugins/asciidoctor-extensions.rb
[2] https://github.com/asciidoctor/asciidoctor/blob/master/LICENSE 
[3] 
https://github.com/apache/ignite/blob/master/docs/_sass/rouge-base16-solarized.scss
[4] https://github.com/rouge-ruby/rouge/blob/master/LICENSE
[5] https://github.com/apache/ignite/blob/master/docs/assets/js/anchor.min.js
[6] https://github.com/bryanbraun/anchorjs#license
[7] 
https://github.com/apache/ignite/blob/master/docs/assets/js/jquery.swiftype.autocomplete.js



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Usage of BinaryObject in Spring Data Queries

[Mikhail Petrov]

Manuel Nunez, Ilya Kasnacheev,

I'm working on the support of thin clients for ignite spring data 
integration. And I faced that in method 
IgniteRepositoryQuery#rowToEntity that was introduced by ticket [1], 
BinaryObject is used to create cache value class from SQL result row and 
to determine class fields.


Could you clarify why this particular way was chosen?

At first glance, the same result can be achieved using 
FieldsQueryCursor#getFieldName and fields of cache value class obtained 
merely through reflection. It seems that it can help to avoid 
unnecessary serialization while BinaryObject building and avoid using 
node-specific methods (such as QueryCursorEx#fieldsMeta, 
IgniteConfiguration#getClassLoader, and so on). As a result, it can also 
make it possible to reuse spring data query logic with a thin client 
without code duplication.


WDYT?

[1] https://issues.apache.org/jira/browse/IGNITE-13005

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

[Denis Magda]

Saikat, Alex,

Based on your inputs here, it sounds like once Ignite 2.9 gets released,
all the integrations that made their way to the extensions repo [1] will
get stuck in limbo for some time. What I mean here:

   1. While the users will be bumping up their ignite-core,
   ignite-indexing, etc. versions to 2.9, they won't find a 2.9 artifact for
   Kafka, Camel and other extensions
   2. Also, the users won't find 1.0 versions of those extensions that also
   need to be released

So, it's unclear how those users are supposed to upgrade to Ignite 2.9 if
they use any of the extensions. Is it safe to use a 2.8 version of an
extension? Or, should we release the 1.0 versions of all the migrated
extensions together with 2.9?


[1] https://github.com/apache/ignite-extensions/tree/master/modules


-
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 Vladimir Steshin privately
> >> and
> >>  decided to revert this ticket. I will do it today (after TC bot
> visa)
> >> >> if
> >>  there are no objections.
> >> 
> >>  [1]: https://issues.apache.org/jira/browse/IGNITE-13465
> >>  [2]: https://issues.apache.org/jira/browse/IGNITE-13134
> >> 
> >>  пн, 21 сент. 2020 г. в 11:08, Alex Plehanov <
> plehanov.a...@gmail.com
> >> >:
> >> 
> >> > Guys,
> >> >
> >> > During internal testing, we've found a critical bug with
> >> > discovery (cluster falls 

Re: Instance of IgniteClient in Multi threaded application

[Denis Magda]

Also, as long as you're on Java, you can add the Ignite thick client to the
comparison list. It can behave faster for your workload.

-
Denis


On Mon, Oct 12, 2020 at 6:14 AM Pavel Tupitsyn  wrote:

> It depends. The only way to tell is to measure and profile your specific
> use case.
>
> What I'm trying to say is:
> 1. Start with one instance - low complexity, low overhead.
> 2. If performance needs improvement, and Ignite is determined to be a
> bottleneck,
> consider trying multiple instances, this may help in some cases.
>
>
> On Mon, Oct 12, 2020 at 3:59 PM midulaj  wrote:
>
> > Thanks Pavel,
> >
> > How can we categorize the high load scenarios in the case of Ignite..If
> my
> > requests to Ingnite are more than 1000 per second then can i take it as a
> > high-load or i can consider more figures for high load
> >
> >
> >
> > --
> > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >
>

[jira] [Created] (IGNITE-13573) Website has comments before DOCTYPE

[Sebb (Jira)]

Sebb created IGNITE-13573:
-

 Summary: Website has comments before DOCTYPE
 Key: IGNITE-13573
 URL: https://issues.apache.org/jira/browse/IGNITE-13573
 Project: Ignite
  Issue Type: Bug
Reporter: Sebb


The website has some comments before the  tag.

This is not recommended, as it causes issues for some browsers.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Sql consistency when partition evicts.

[Ivan Daschinsky]

Hi!
I found recently quite surprising on the first sight behaviour.

Scenario:
1. Start 2 node with indexed atomic partitioned cache with 0 backups.
2. Load sufficient amout of data (or emulate slow removal from idx)
4. Start another node.
4. Perform SELECT * FROM .

Due to partition eviction, number of returned rows from SQL are
sufficiently bigger than
expected. Reproducer is attached to jira issue [1]

Is this known issue? Is it expected behaviour due to our SQL indices design?

-
[1] -- https://issues.apache.org/jira/browse/IGNITE-13572

-- 
Sincerely yours, Ivan Daschinskiy

[jira] [Created] (IGNITE-13572) Duplicates in select query during partition eviction.

[Ivan Daschinskiy (Jira)]

Ivan Daschinskiy created IGNITE-13572:
-

 Summary: Duplicates in select query during partition eviction.
 Key: IGNITE-13572
 URL: https://issues.apache.org/jira/browse/IGNITE-13572
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8.1, 2.9
Reporter: Ivan Daschinskiy


Scenario:

# Starts 2 node with indexed atomic partitioned cache with 0 backups.
# Loads sufficient amout of data (or emulate slow removal from idx)
# Start another node.
# Perform SELECT * FROM .

Reproducer is attached



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13571) Pme-free test should use 9 server nodes

[Anton Vinogradov (Jira)]

Anton Vinogradov created IGNITE-13571:
-

 Summary: Pme-free test should use 9 server nodes
 Key: IGNITE-13571
 URL: https://issues.apache.org/jira/browse/IGNITE-13571
 Project: Ignite
  Issue Type: Task
Reporter: Anton Vinogradov
Assignee: Anton Vinogradov






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Instance of IgniteClient in Multi threaded application

[Pavel Tupitsyn]

It depends. The only way to tell is to measure and profile your specific
use case.

What I'm trying to say is:
1. Start with one instance - low complexity, low overhead.
2. If performance needs improvement, and Ignite is determined to be a
bottleneck,
consider trying multiple instances, this may help in some cases.


On Mon, Oct 12, 2020 at 3:59 PM midulaj  wrote:

> Thanks Pavel,
>
> How can we categorize the high load scenarios in the case of Ignite..If my
> requests to Ingnite are more than 1000 per second then can i take it as a
> high-load or i can consider more figures for high load
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

Re: Instance of IgniteClient in Multi threaded application

[midulaj]

Thanks Pavel,

How can we categorize the high load scenarios in the case of Ignite..If my
requests to Ingnite are more than 1000 per second then can i take it as a
high-load or i can consider more figures for high load



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

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

[Alexey Goncharuk]

Alexey,

For me, all three look quite critical as they: address a memory leak,
address a usability/performance issue with no workaround, and address a
regression in 2.8. If we want to limit the scope, I would still include the
memory leak fix, though.

Thoughts?

пн, 12 окт. 2020 г. в 13:07, Alex Plehanov :

> Guys,
>
> I've found 3 more tickets which were targeted to 2.9 but merged only to the
> master branch ([1], [2], [3]).
> Do we need these tickets in 2.9? Are they critical?
>
> [1]: https://issues.apache.org/jira/browse/IGNITE-12350
> [2]: https://issues.apache.org/jira/browse/IGNITE-13376
> [3]: https://issues.apache.org/jira/browse/IGNITE-13280
>
> вс, 11 окт. 2020 г. в 16:11, Nikolay Izhikov :
>
> > Igniters,
> >
> > IGNITE-13553 fixed and cherry-picked to 2.9.
> > We can continue with the release.
> >
> > > 10 окт. 2020 г., в 00:00, Denis Magda  написал(а):
> > >
> > > 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 <
> saikat.mai...@gmail.com
> > >:
> > 
> > > 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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > 

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

[Vladislav Pyatkov]

This patch [1] interesting only a deployment where clients often
reconnecting (stopping/starting) to cluster.
In these cases Coordinator node could fail by OOM, even the cluster did not
use MVCC caches.

On Mon, Oct 12, 2020 at 1:41 PM Zhenya Stanilovsky
 wrote:

>
>
> without [2] and [3] we obtain unexpected fields in index creation and as a
> consequence buggy sql execution and pla of course.
>
>
>
> >Guys,
> >
> >I've found 3 more tickets which were targeted to 2.9 but merged only to
> the
> >master branch ([1], [2], [3]).
> >Do we need these tickets in 2.9? Are they critical?
> >
> >[1]:  https://issues.apache.org/jira/browse/IGNITE-12350
> >[2]:  https://issues.apache.org/jira/browse/IGNITE-13376
> >[3]:  https://issues.apache.org/jira/browse/IGNITE-13280
> >
> >вс, 11 окт. 2020 г. в 16:11, Nikolay Izhikov < nizhi...@apache.org >:
> >
> >> Igniters,
> >>
> >> IGNITE-13553 fixed and cherry-picked to 2.9.
> >> We can continue with the release.
> >>
> >> > 10 окт. 2020 г., в 00:00, Denis Magda < dma...@apache.org >
> написал(а):
> >> >
> >> > 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 < nizhi...@apache.org
> >
> >> 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 < dma...@apache.org >
> написал(а):
> >> >>>
> >> >>> @Alex Plehanov < plehanov.a...@gmail.com >,
> >> >>>
> >> >>> 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 <
> saikat.mai...@gmail.com
> >> >:
> >> 
> >> > 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
> >> 

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

[Zhenya Stanilovsky]

without [2] and [3] we obtain unexpected fields in index creation and as a 
consequence buggy sql execution and pla of course.


 
>Guys,
>
>I've found 3 more tickets which were targeted to 2.9 but merged only to the
>master branch ([1], [2], [3]).
>Do we need these tickets in 2.9? Are they critical?
>
>[1]:  https://issues.apache.org/jira/browse/IGNITE-12350
>[2]:  https://issues.apache.org/jira/browse/IGNITE-13376
>[3]:  https://issues.apache.org/jira/browse/IGNITE-13280
>
>вс, 11 окт. 2020 г. в 16:11, Nikolay Izhikov < nizhi...@apache.org >:
> 
>> Igniters,
>>
>> IGNITE-13553 fixed and cherry-picked to 2.9.
>> We can continue with the release.
>>
>> > 10 окт. 2020 г., в 00:00, Denis Magda < dma...@apache.org > написал(а):
>> >
>> > 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 < nizhi...@apache.org >
>> 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 < dma...@apache.org > написал(а):
>> >>>
>> >>> @Alex Plehanov < plehanov.a...@gmail.com >,
>> >>>
>> >>> 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 < saikat.mai...@gmail.com
>> >:
>> 
>> > 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 < mr.wei...@gmail.com >
>> >> wrote:
>> >
>> >> It seems that gitbox.apache.org is not available on CI/CD.
>> >>
>> >> I will try to update 

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

[Alex Plehanov]

Guys,

I've found 3 more tickets which were targeted to 2.9 but merged only to the
master branch ([1], [2], [3]).
Do we need these tickets in 2.9? Are they critical?

[1]: https://issues.apache.org/jira/browse/IGNITE-12350
[2]: https://issues.apache.org/jira/browse/IGNITE-13376
[3]: https://issues.apache.org/jira/browse/IGNITE-13280

вс, 11 окт. 2020 г. в 16:11, Nikolay Izhikov :

> Igniters,
>
> IGNITE-13553 fixed and cherry-picked to 2.9.
> We can continue with the release.
>
> > 10 окт. 2020 г., в 00:00, Denis Magda  написал(а):
> >
> > 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:
> >>> 

[RESULT] [VOTE] Release Apache Ignite 2.9.0-rc2

[Alex Plehanov]

Dear community,

The vote for a new release candidate is closed, now.
Vote result: Vote not passes with one -1 vote.

-1 votes:
- Nikolay Izhikov (binding)

Vote thread:
http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-9-0-RC2-td49480.html

I will create a new release candidate with fixed tickets.

[jira] [Created] (IGNITE-13570) Migrate OSGI module to ignite-extensions

[Alexey Goncharuk (Jira)]

Alexey Goncharuk created IGNITE-13570:
-

 Summary: Migrate OSGI module to ignite-extensions
 Key: IGNITE-13570
 URL: https://issues.apache.org/jira/browse/IGNITE-13570
 Project: Ignite
  Issue Type: Sub-task
Reporter: Alexey Goncharuk


Migrate OSGI module to ignite-extensions

https://github.com/apache/ignite-extensions 

Details: 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[Nikolay Izhikov]

Hello, Igniters.

It seems, fails of Cache (Restarts) suite not related to my changes.

I see a lot of failed rebalance tests.
So, maybe fails related to «IGNITE-13441 Fixes for TC stabilization» changes?

Alex, can you, please, take a look.


[1] 
https://github.com/apache/ignite/commit/f45c470e12c6187afca16996d9c01ddb9fa79869


> 12 окт. 2020 г., в 02:56, dpavlov.ta...@gmail.com написал(а):
> 
> Hi Igniters,
> 
> I've detected some new issue on TeamCity to be handled. You are more than 
> welcomed to help.
> 
> If your changes can lead to this failure(s): We're grateful that you were a 
> volunteer to make the contribution to this project, but things change and you 
> may no longer be able to finalize your contribution.
> Could you respond to this email and indicate if you wish to continue and fix 
> test failures or step down and some committer may revert you commit. 
> 
> *New Critical Failure in master Cache (Restarts) 1 
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CacheRestarts1?branch=%3Cdefault%3E
> Changes may lead to failure were done by 
>- nikolay  
> https://ci.ignite.apache.org/viewModification.html?modId=908313
> 
>- 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 02:56:23 12-10-2020 

Re: [DISCUSS] Remove a Patch-file contribution approach from guides

[Ilya Kasnacheev]

+1

I've never seen this patchway in action nor did I knew about its existence.

Regards,
-- 
Ilya Kasnacheev


вс, 11 окт. 2020 г. в 04:43, Saikat Maitra :

> +1
>
> Regards,
> Saikat
>
> On Sat, Oct 10, 2020 at 8:22 AM Alexey Zinoviev 
> wrote:
>
> > Agree, need to update
> >
> > сб, 10 окт. 2020 г., 15:35 Ivan Pavlukhin :
> >
> > > Folks,
> > >
> > > A new contributor Bojidar tried to used a Patch-file contribution
> > > approach [1]. The approach is stated in our guides [2]. I suppose that
> > > the approach is obsolete. I several threads seem to confirm it [3, 4].
> > >
> > > If nobody objects I will remove a section [2] from the guide.
> > >
> > > [1]
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Introduction-td49570.html
> > > [2]
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-2.CreateaPatch-file
> > > [3]
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/ci-ignite-apache-Run-all-for-patch-jira-number-td24861.html
> > > [4]
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Disabling-patch-validation-mechanism-on-TC-td5400.html
> > >
> > > --
> > >
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> >
>

Re: Migration of spring-data modules to ignite-extensions

[Mikhail Petrov]

Saikat,

Thanks a lot for the review.

Anyone else want to review PR [1] with migration of spring-data to 
ignite-extensions repository?



[1] - https://github.com/apache/ignite-extensions/pull/25

On 10.10.2020 07:15, Saikat Maitra wrote:

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

Re: ignite-extenisions naming policy

[Petr Ivanov]

Hi!


Yes., the git tag.

The naming is good. thanks.
Can you also rename current one, please, or add new referring the old with 
agreed naming?


> On 10 Oct 2020, at 07:25, Saikat Maitra  wrote:
> 
> 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?