Re: [ANNOUNCE] Apache Ignite ML Extension 1.0.0 released

[Ivan Daschinsky]

All parsers also have been uploaded to maven central:
https://central.sonatype.com/artifact/org.apache.ignite/ignite-ml-ext/dependents

пн, 29 янв. 2024 г. в 12:00, Ivan Daschinsky :

> The Apache Ignite Community is pleased to announce the release of Apache
> Ignite ML Extension 1.0.0.
>
> You can download source release here:
> https://downloads.apache.org/ignite/ignite-extensions/ignite-ml-ext/1.0.0/
>
> Artifacts can be downloaded from here:
> https://central.sonatype.com/artifact/org.apache.ignite/ignite-ml-ext
>
> Please let us know if you encounter any problems:
> https://ignite.apache.org/community/resources.html#ask
>
> ---
> Best Regards
> Ivan Daschinsky
> on behalf of Apache Ignite PMC
>

[ANNOUNCE] Apache Ignite ML Extension 1.0.0 released

[Ivan Daschinsky]

The Apache Ignite Community is pleased to announce the release of Apache
Ignite ML Extension 1.0.0.

You can download source release here:
https://downloads.apache.org/ignite/ignite-extensions/ignite-ml-ext/1.0.0/

Artifacts can be downloaded from here:
https://central.sonatype.com/artifact/org.apache.ignite/ignite-ml-ext

Please let us know if you encounter any problems:
https://ignite.apache.org/community/resources.html#ask

---
Best Regards
Ivan Daschinsky
on behalf of Apache Ignite PMC

[VOTE] Release Apache Ignite ML Extension 1.0.0 RC1

[Ivan Daschinsky]

Dear community,

The release of Apache Ignite ML Extension 1.0.0. RC1 has been accepted

Vote result:
+1 -- 4 votes (4 binding votes)
0 -- 0 votes
-1 -- 0 votes
+1 votes:
Nikita Amelchev
Alex Plehanov
Maxim Muzafarov
Alexey Zinoviev

The new release will be announced soon.

Re: [VOTE] Release Apache Ignite ML Extension 1.0.0 RC1

[Ivan Daschinsky]

Sorry for my mistake, this vote will be open till Jan 26, 2024

вт, 23 янв. 2024 г. в 16:27, Ivan Daschinsky :

> Dear Community,
> I am happy to start this voting thread.
>
> The release candidate have been uploaded to:
>
> https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-ml-ext-1.0.0-rc1/
>
> The staging maven repository is here:
> https://repository.apache.org/content/repositories/orgapacheignite-1560
>
> The release notes are here:
>
> https://github.com/apache/ignite-extensions/blob/ignite-ml-ext-1.0.0-rc1/modules/ml-ext/ml/RELEASE_NOTES.txt
>
> The release checker results are here:
> https://github.com/apache/ignite-extensions/actions/runs/7626105841
>
> The TC run is here:
>
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Ml/7716025?hideProblemsFromDependencies=false=false
>
>
>
> The vote is formal, see voting guidelines
> https://www.apache.org/foundation/voting.html
>
> +1 - to accept
> 0 - don't care either way
> -1 - DO NOT accept (explain why)
>
> See notes on how to verify release here
> https://www.apache.org/info/verification.html
> and
>
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
>
>
> This vote will be open for at least 4 days till Fri Jan 26, 2022,
> 17:00 UTC+3. Please, write me down the thread if you need
> additional time to check the release.
>


-- 
Sincerely yours, Ivan Daschinskiy

[VOTE] Release Apache Ignite ML Extension 1.0.0 RC1

[Ivan Daschinsky]

Dear Community,
I am happy to start this voting thread.

The release candidate have been uploaded to:
https://dist.apache.org/repos/dist/dev/ignite/ignite-extensions/ignite-ml-ext-1.0.0-rc1/

The staging maven repository is here:
https://repository.apache.org/content/repositories/orgapacheignite-1560

The release notes are here:
https://github.com/apache/ignite-extensions/blob/ignite-ml-ext-1.0.0-rc1/modules/ml-ext/ml/RELEASE_NOTES.txt

The release checker results are here:
https://github.com/apache/ignite-extensions/actions/runs/7626105841

The TC run is here:
https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Ml/7716025?hideProblemsFromDependencies=false=false



The vote is formal, see voting guidelines
https://www.apache.org/foundation/voting.html

+1 - to accept
0 - don't care either way
-1 - DO NOT accept (explain why)

See notes on how to verify release here
https://www.apache.org/info/verification.html
and
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification


This vote will be open for at least 4 days till Fri Jan 26, 2022,
17:00 UTC+3. Please, write me down the thread if you need
additional time to check the release.

Re: Ignite Extensions

[Ivan Daschinsky]

Also, I have updated dependencies and fixed native BLAS integration (tested
on ubuntu 22.04 with Intel MKL)

пн, 22 янв. 2024 г. в 19:18, Ivan Daschinsky :

> Hi, Steven. Currently I am preparing an initial release of the ML
> extension. Just thinking about creating a new thread and here you are :)
> The release branch is ready, I just need to prepare artifacts and upload
> them to staging. Then I am going to start the vote thread.
>
>
> https://github.com/apache/ignite-extensions/tree/release/ignite-ml-ext-1.0.0
>
> пн, 22 янв. 2024 г. в 18:15, Stephen Darlington :
>
>> Hi all,
>>
>> With Ignite 2.16 now out, is there any movement towards releasing some of
>> the Ignite Extensions?
>>
>> We have a question in the user mailing list about the ML extensions, which
>> were moved from core to extensions. And I'd like to see the SpringBoot
>> extensions released so that we can support current versions (3.x does not
>> work with Ignite out of the box).
>>
>> Regards,
>> Stephen
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Ignite Extensions

[Ivan Daschinsky]

Hi, Steven. Currently I am preparing an initial release of the ML
extension. Just thinking about creating a new thread and here you are :)
The release branch is ready, I just need to prepare artifacts and upload
them to staging. Then I am going to start the vote thread.

https://github.com/apache/ignite-extensions/tree/release/ignite-ml-ext-1.0.0

пн, 22 янв. 2024 г. в 18:15, Stephen Darlington :

> Hi all,
>
> With Ignite 2.16 now out, is there any movement towards releasing some of
> the Ignite Extensions?
>
> We have a question in the user mailing list about the ML extensions, which
> were moved from core to extensions. And I'd like to see the SpringBoot
> extensions released so that we can support current versions (3.x does not
> work with Ignite out of the box).
>
> Regards,
> Stephen
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [VOTE] Release Apache Ignite 2.16.0 RC0

[Ivan Daschinsky]

+1 from me (binding)

1. Checked checksums
2. Checked C++/ODBC driver: built from source and ran examples on Ubuntu
22.04/gcc 11.4.0/OpenJDK-Temurin 17.0.8
3. Checked ODBC driver with pyodbc (python 3.11 + pyodbc 4.0.35). Checked
on calcite and H2 engines. (Ubuntu 22.04)

вт, 19 дек. 2023 г. в 13:54, Zhenya Stanilovsky :

>
> Finally i build it (some local maven problems).
> Check compilation, run calcite tests.
> +1 (non-binding)
>
> >
> >>
> >>>Hello, Zhenya.
> >>>
> >>>Java profiles should be activated automatically (on reload maven
> >>>project). Which JDK are you using? Is the project built from maven?
> >>>
> >>>I can't reproduce on HotSpot 1.8.0_201-b09, OpenJDK 21+35-2513.
> >>>
> >>>вт, 19 дек. 2023г. в 11:16, Zhenya Stanilovsky <
> arzamas...@mail.ru.invalid >:
> 
> 
>  Hi, probably it`s a kind of problem from my side, but cloning by tag
> and further steps:
>  * change profile to java-8
>  * Reload all maven Projects
>  * Try to run: ScriptTestSuite will raise guava dependency problem:
> 
> /ignite/internal/processors/query/calcite/sql/IgniteSqlRollback.java:20:33
>  java: package com.google.common.collect does not exist
>  ---
>  * change profile to java-9
>  * reload
>  * the same problem :
> 
> modules/core/src/test/java/org/apache/ignite/testframework/GridTestUtils.java:79:33
>  java: package com.google.common.collect does not exist
> 
>  probably i need to clean all and try to rebuild from scratch .. for
> now it`s not clear for me.
> 
>  >+1
>  >
>  >- Started the node from binaries
>  >- Tested .NET examples
>  >- Tested NuGet packages
>  >
>  >On Sun, Dec 17, 2023 at 2:48PM Nikita Amelchev <
> namelc...@apache.org >
>  >wrote:
>  >
>  >> Dear Community,
>  >>
>  >> The release candidate is ready.
>  >>
>  >> I have uploaded release candidate to
>  >>  https://dist.apache.org/repos/dist/dev/ignite/2.16.0-rc0
>  >>  https://dist.apache.org/repos/dist/dev/ignite/packages_2.16.0-rc0
>  >>
>  >> The following staging can be used for testing:
>  >>
> https://repository.apache.org/content/repositories/orgapacheignite-1559
>  >>
>  >> Tag name is 2.16.0-rc0:
>  >>  https://github.com/apache/ignite/releases/tag/2.16.0-rc0
>  >>
>  >> 2.16.0 most important changes:
>  >> * Cache dumps;
>  >> * Calcite engine: added hints, became more stable, covered with
>  >> diagnostic tools;
>  >> * Fixes to support JDK 14-21;
>  >> * Cluster Management API (IEP-81);
>  >> * Java thin client: Service Awareness feature;
>  >> etc.
>  >>
>  >> RELEASE NOTES:
>  >>
>  >>
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.16
>  >>
>  >> Complete list of resolved issues:
>  >>
>  >>
> https://issues.apache.org/jira/browse/IGNITE-19650?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.16%27))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20AND%20resolution%20in(Fixed%2C%20Done%2C%20Implemented%2C%20Delivered)%20ORDER%20BY%20priority
>  >>
>  >> DEVNOTES
>  >>
>  >>
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.16
>  >>
>  >> The vote is formal, see voting guidelines
>  >>  https://www.apache.org/foundation/voting.html
>  >>
>  >> +1 - to accept Apache Ignite 2.16.0-rc0
>  >> 0 - don't care either way
>  >> -1 - DO NOT accept Apache Ignite 2.16.0-rc0 (explain why)
>  >>
>  >> See notes on how to verify release here
>  >>  https://www.apache.org/info/verification.html
>  >> and
>  >>
>  >>
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
>  >>
>  >> This vote will be open till Sun December 24, 2023, 15:00 UTC.
>  >>
>  >>
> https://www.timeanddate.com/countdown/vote?iso=20231224T15=0=VOTE+on+the+Apache+Ignite+Release+2.16.0+RC0=sanserif
>  >>
>  >> --
>  >> Best wishes,
>  >> Amelchev Nikita
>  >>
> 
> 
> 
> 
> >>>
> >>>
> >>>--
> >>>Best wishes,
> >>>Amelchev Nikita
> >>
> >>
> >>
> >>

Re: New Apache Ignite PMC member: Nikita Amelchev

[Ivan Daschinsky]

Congratulations, you deserve it

On Wed, Nov 22, 2023, 18:10 Nikita Amelchev  wrote:

> Thank you everyone, I'm very pleased!
>
> ср, 22 нояб. 2023 г. в 15:46, Ilya Shishkov :
> >
> > Congratulations, Nikita!
> >
> > ср, 22 нояб. 2023 г. в 14:53, Maksim Timonin :
> > >
> > > Congratulations!
> > >
> > > On Wed, Nov 22, 2023 at 2:29 PM Anton Vinogradov 
> wrote:
> > >
> > > > Welcome aboard :)
> > > >
> > > > On Wed, Nov 22, 2023 at 2:11 PM Maxim Muzafarov 
> wrote:
> > > >
> > > > > My congratulations, Nikita!
> > > > >
> > > > > On Tue, 21 Nov 2023 at 15:20, Dmitriy Pavlov 
> wrote:
> > > > > >
> > > > > > Hello Igniters,
> > > > > >
> > > > > > The Project Management Committee (PMC) for Apache Ignite
> > > > > > has invited Nikita Amelchev to become a member of PMC and we are
> > > > pleased
> > > > > > to announce that he has accepted.
> > > > > >
> > > > > > We appreciate his constant efforts in improving Apache Ignite
> code, as
> > > > > well
> > > > > > as efforts in preparing 2 major releases.
> > > > > >
> > > > > > A PMC member helps manage and guide the direction of the project.
> > > > > >
> > > > > > Congratulations on your new role! Keep the pace!
> > > > > >
> > > > > > Best Regards
> > > > > > Dmitriy Pavlov
> > > > > > on behalf of Apache Ignite PMC
> > > > >
> > > >
>
>
>
> --
> Best wishes,
> Amelchev Nikita
>

Re: Remove sonar step from PR checks

[Ivan Daschinsky]

>> No, I just think that we should remove 1 yaml file unless the sonar
check is not properly configured.
No, I just think that we should remove 1 yaml file unless the sonar check
is properly configured. -- corrected


чт, 28 сент. 2023 г. в 14:12, Ivan Daschinsky :

> No, I just think that we should remove 1 yaml file unless the sonar check
> is not properly configured.
>
> чт, 28 сент. 2023 г. в 14:09, Anton Vinogradov :
>
>> Ivan,
>> According to your proposal, should we also remove the "Platform .NET"
>> tests
>> [1] since they are always failed instead of fixing them?
>>
>> [1]
>>
>> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux?branch=%3Cdefault%3E=builds
>>
>> On Thu, Sep 28, 2023 at 1:57 PM Anton Vinogradov  wrote:
>>
>> > > Sonar shows lots of false positives.
>> > Thats not a true.
>> > We have a *bad* code, unfortunatelly, and that's the *reason* of such
>> > hints.
>> > Could you please show "a lot" of false positives?
>> > The url you provided contains a lot of *correct* hints.
>> >
>> > > But constantly red checks lead to ignoring of all checks.
>> > I'm checking each report, and fixed a lot of dummy issues thanks to it.
>> >
>> > On Thu, Sep 28, 2023 at 1:49 PM Ivan Daschinsky 
>> > wrote:
>> >
>> >> Sonar shows lots of false positives. We cannot add //NOSONAR to all of
>> >> them
>> >> -- it is a tremendous job.
>> >> But constantly red checks lead to ignoring of all checks. Simply nobody
>> >> pay
>> >> attention to them. It is not acceptable and contradicts to
>> >> the idea of running these checks.
>> >>
>> >> чт, 28 сент. 2023 г. в 13:43, Anton Vinogradov :
>> >>
>> >> > Removing a quality tool it not a good idea.
>> >> > AFAIU, we have two issues here:
>> >> >
>> >> > 1) Sonar always failed at PR because ot token issues
>> >> > Error: Failed to execute goal
>> >> > org.sonarsource.scanner.maven:sonar-maven-plugin:3.9.1.2184:sonar
>> >> > (default-cli) on project apache-ignite: Project not found. Please
>> check
>> >> the
>> >> > 'sonar.projectKey' and 'sonar.organization' properties, the
>> >> 'SONAR_TOKEN'
>> >> > environment variable, or contact the project administrator -> [Help
>> 1]
>> >> >
>> >> > 2) Sonar shows *correct* hints for a *bad* code we have.
>> >> >
>> >> > Both issues should be solved properly, not by removing the quality
>> tool.
>> >> >
>> >> > My huge -1 here
>> >> >
>> >> > On Thu, Sep 28, 2023 at 1:36 PM Ivan Daschinsky > >
>> >> > wrote:
>> >> >
>> >> > > Hi! It seems that these checks simply don't work, at least for PRs.
>> >> > > Yep, they work ok for master, but some of warnings from these tools
>> >> seem
>> >> > to
>> >> > > be just rubbish, like
>> >> > > this one -- [1].
>> >> > > We should either do a tremendous job to fix these issues or simply
>> >> > disable
>> >> > > these checks.
>> >> > >
>> >> > > Simply ignoring is not an option, I suppose. I think we should at
>> >> least
>> >> > > remove PR checks.
>> >> > > What do you think?
>> >> > >
>> >> > > ---
>> >> > > [1] ---
>> >> > >
>> >> > >
>> >> >
>> >>
>> https://sonarcloud.io/project/issues?resolved=false=true=CODE_SMELL=apache_ignite=AYi0-_4zULfXwSrNiDt_
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Sincerely yours, Ivan Daschinskiy
>> >> > >
>> >> >
>> >>
>> >>
>> >> --
>> >> Sincerely yours, Ivan Daschinskiy
>> >>
>> >
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Remove sonar step from PR checks

[Ivan Daschinsky]

No, I just think that we should remove 1 yaml file unless the sonar check
is not properly configured.

чт, 28 сент. 2023 г. в 14:09, Anton Vinogradov :

> Ivan,
> According to your proposal, should we also remove the "Platform .NET" tests
> [1] since they are always failed instead of fixing them?
>
> [1]
>
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux?branch=%3Cdefault%3E=builds
>
> On Thu, Sep 28, 2023 at 1:57 PM Anton Vinogradov  wrote:
>
> > > Sonar shows lots of false positives.
> > Thats not a true.
> > We have a *bad* code, unfortunatelly, and that's the *reason* of such
> > hints.
> > Could you please show "a lot" of false positives?
> > The url you provided contains a lot of *correct* hints.
> >
> > > But constantly red checks lead to ignoring of all checks.
> > I'm checking each report, and fixed a lot of dummy issues thanks to it.
> >
> > On Thu, Sep 28, 2023 at 1:49 PM Ivan Daschinsky 
> > wrote:
> >
> >> Sonar shows lots of false positives. We cannot add //NOSONAR to all of
> >> them
> >> -- it is a tremendous job.
> >> But constantly red checks lead to ignoring of all checks. Simply nobody
> >> pay
> >> attention to them. It is not acceptable and contradicts to
> >> the idea of running these checks.
> >>
> >> чт, 28 сент. 2023 г. в 13:43, Anton Vinogradov :
> >>
> >> > Removing a quality tool it not a good idea.
> >> > AFAIU, we have two issues here:
> >> >
> >> > 1) Sonar always failed at PR because ot token issues
> >> > Error: Failed to execute goal
> >> > org.sonarsource.scanner.maven:sonar-maven-plugin:3.9.1.2184:sonar
> >> > (default-cli) on project apache-ignite: Project not found. Please
> check
> >> the
> >> > 'sonar.projectKey' and 'sonar.organization' properties, the
> >> 'SONAR_TOKEN'
> >> > environment variable, or contact the project administrator -> [Help 1]
> >> >
> >> > 2) Sonar shows *correct* hints for a *bad* code we have.
> >> >
> >> > Both issues should be solved properly, not by removing the quality
> tool.
> >> >
> >> > My huge -1 here
> >> >
> >> > On Thu, Sep 28, 2023 at 1:36 PM Ivan Daschinsky 
> >> > wrote:
> >> >
> >> > > Hi! It seems that these checks simply don't work, at least for PRs.
> >> > > Yep, they work ok for master, but some of warnings from these tools
> >> seem
> >> > to
> >> > > be just rubbish, like
> >> > > this one -- [1].
> >> > > We should either do a tremendous job to fix these issues or simply
> >> > disable
> >> > > these checks.
> >> > >
> >> > > Simply ignoring is not an option, I suppose. I think we should at
> >> least
> >> > > remove PR checks.
> >> > > What do you think?
> >> > >
> >> > > ---
> >> > > [1] ---
> >> > >
> >> > >
> >> >
> >>
> https://sonarcloud.io/project/issues?resolved=false=true=CODE_SMELL=apache_ignite=AYi0-_4zULfXwSrNiDt_
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Sincerely yours, Ivan Daschinskiy
> >> > >
> >> >
> >>
> >>
> >> --
> >> Sincerely yours, Ivan Daschinskiy
> >>
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Remove sonar step from PR checks

[Ivan Daschinsky]

I have already shown one example.
Here is another one --
https://sonarcloud.io/project/issues?resolved=false=BUG=apache_ignite=AYdcaDNkmXUD5o3U1M1d

Also, it is required to exclude from check examples, tests, jmh benchmarks
and so on. A lot of useless information doesn't help to find new issues in
new code.
And this is one of the most important goals of such a tool.

чт, 28 сент. 2023 г. в 13:58, Anton Vinogradov :

> > Sonar shows lots of false positives.
> Thats not a true.
> We have a *bad* code, unfortunatelly, and that's the *reason* of such
> hints.
> Could you please show "a lot" of false positives?
> The url you provided contains a lot of *correct* hints.
>
> > But constantly red checks lead to ignoring of all checks.
> I'm checking each report, and fixed a lot of dummy issues thanks to it.
>
> On Thu, Sep 28, 2023 at 1:49 PM Ivan Daschinsky 
> wrote:
>
> > Sonar shows lots of false positives. We cannot add //NOSONAR to all of
> them
> > -- it is a tremendous job.
> > But constantly red checks lead to ignoring of all checks. Simply nobody
> pay
> > attention to them. It is not acceptable and contradicts to
> > the idea of running these checks.
> >
> > чт, 28 сент. 2023 г. в 13:43, Anton Vinogradov :
> >
> > > Removing a quality tool it not a good idea.
> > > AFAIU, we have two issues here:
> > >
> > > 1) Sonar always failed at PR because ot token issues
> > > Error: Failed to execute goal
> > > org.sonarsource.scanner.maven:sonar-maven-plugin:3.9.1.2184:sonar
> > > (default-cli) on project apache-ignite: Project not found. Please check
> > the
> > > 'sonar.projectKey' and 'sonar.organization' properties, the
> 'SONAR_TOKEN'
> > > environment variable, or contact the project administrator -> [Help 1]
> > >
> > > 2) Sonar shows *correct* hints for a *bad* code we have.
> > >
> > > Both issues should be solved properly, not by removing the quality
> tool.
> > >
> > > My huge -1 here
> > >
> > > On Thu, Sep 28, 2023 at 1:36 PM Ivan Daschinsky 
> > > wrote:
> > >
> > > > Hi! It seems that these checks simply don't work, at least for PRs.
> > > > Yep, they work ok for master, but some of warnings from these tools
> > seem
> > > to
> > > > be just rubbish, like
> > > > this one -- [1].
> > > > We should either do a tremendous job to fix these issues or simply
> > > disable
> > > > these checks.
> > > >
> > > > Simply ignoring is not an option, I suppose. I think we should at
> least
> > > > remove PR checks.
> > > > What do you think?
> > > >
> > > > ---
> > > > [1] ---
> > > >
> > > >
> > >
> >
> https://sonarcloud.io/project/issues?resolved=false=true=CODE_SMELL=apache_ignite=AYi0-_4zULfXwSrNiDt_
> > > >
> > > >
> > > >
> > > > --
> > > > Sincerely yours, Ivan Daschinskiy
> > > >
> > >
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Remove sonar step from PR checks

[Ivan Daschinsky]

Sonar shows lots of false positives. We cannot add //NOSONAR to all of them
-- it is a tremendous job.
But constantly red checks lead to ignoring of all checks. Simply nobody pay
attention to them. It is not acceptable and contradicts to
the idea of running these checks.

чт, 28 сент. 2023 г. в 13:43, Anton Vinogradov :

> Removing a quality tool it not a good idea.
> AFAIU, we have two issues here:
>
> 1) Sonar always failed at PR because ot token issues
> Error: Failed to execute goal
> org.sonarsource.scanner.maven:sonar-maven-plugin:3.9.1.2184:sonar
> (default-cli) on project apache-ignite: Project not found. Please check the
> 'sonar.projectKey' and 'sonar.organization' properties, the 'SONAR_TOKEN'
> environment variable, or contact the project administrator -> [Help 1]
>
> 2) Sonar shows *correct* hints for a *bad* code we have.
>
> Both issues should be solved properly, not by removing the quality tool.
>
> My huge -1 here
>
> On Thu, Sep 28, 2023 at 1:36 PM Ivan Daschinsky 
> wrote:
>
> > Hi! It seems that these checks simply don't work, at least for PRs.
> > Yep, they work ok for master, but some of warnings from these tools seem
> to
> > be just rubbish, like
> > this one -- [1].
> > We should either do a tremendous job to fix these issues or simply
> disable
> > these checks.
> >
> > Simply ignoring is not an option, I suppose. I think we should at least
> > remove PR checks.
> > What do you think?
> >
> > ---
> > [1] ---
> >
> >
> https://sonarcloud.io/project/issues?resolved=false=true=CODE_SMELL=apache_ignite=AYi0-_4zULfXwSrNiDt_
> >
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Remove sonar step from PR checks

[Ivan Daschinsky]

Hi! It seems that these checks simply don't work, at least for PRs.
Yep, they work ok for master, but some of warnings from these tools seem to
be just rubbish, like
this one -- [1].
We should either do a tremendous job to fix these issues or simply disable
these checks.

Simply ignoring is not an option, I suppose. I think we should at least
remove PR checks.
What do you think?

---
[1] ---
https://sonarcloud.io/project/issues?resolved=false=true=CODE_SMELL=apache_ignite=AYi0-_4zULfXwSrNiDt_



--
Sincerely yours, Ivan Daschinskiy

Re: Removal of ignite ml module (or moving it to extensions)

[Ivan Daschinsky]

PRs have been merged. Many thanks for review to Nikita Amelchev and Aleksei
Zinoviev

пт, 25 авг. 2023 г. в 17:05, Nikita Amelchev :

> +1 for moving to extensions
>
> This module is good as an extension:
> - does not depend on the internal Ignite API,
> - the released module will be compatible with any required version of
> Ignite using the provided dependency scope.
>
> Ivan, I have reviewed your patch, LGTM.
>
> чт, 17 авг. 2023 г. в 17:06, Dmitry Pavlov :
> >
> > +1 for Apache Way in decision making (it states there should not be time
> pressure for the decision making).
> >
> > 0 for removal
> > 0 for moving to extensions
> >
> > but since Aleksei is an expert here, it makes sense to me to wait for
> him.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > On 2023/08/16 17:32:55 Aleksei Zinovev wrote:
> > > Hi, I have objection for fast merging, (not for moving) as a module
> > > maintainer.
> > >
> > > I never used ignite extension, need a time to be familiar with it and
> test
> > > the pr.
> > >
> > > Please postpone it till 10 september.
> > >
> > > I don't understand reasons to do it so fast. I suppose it's ok to wait
> > > 15-20 days with PR
> > >
> > > Thanks for collaboration and doing this work.
> > >
>
>
>
> --
> Best wishes,
> Amelchev Nikita
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [PROPOSAL] Move Ignite 2.x to JDK11 compilation

[Ivan Daschinsky]

+1, sounds reasonable for the open source project. IMHO, Eclipse Temurin
JDK is a rule of thumb choice nowadays.

ср, 30 авг. 2023 г. в 18:40, Peter Ivanov :

> Hi, Igniters!
>
> As part of this proposal I would also like to discuss the JDK vendors we
> are using on our CI platforms TeamCIty.
> Historically, Ignite 2.x is being built under Oracle's edition - mostly
> because of some features like JFR or similar.
> However today we have pretty much solid alternative represented by OpenJDK
> and its most popular build Eclipse Temurin, which provides every required
> version for our needs (and especially LTS versions 1.8, 11 and 17) with all
> necessary updates.
>
> So, I suggest we update our build agents for TeamCity accordingly, provide
> OpenJDK framework for those 3 major versions and discontinue Oracle's
> builds.
> WDYT?
>
> пт, 25 авг. 2023 г. в 12:13, Ivan Daschinsky :
>
> > +1. It's time to do it at last.
> >
> > пт, 25 авг. 2023 г. в 12:06, Peter Ivanov :
> >
> > > Mostly, yes.
> > >
> > > In other words - proposal is about starting shipping Apache Ignite
> > releases
> > > with JDK11 compiled binaries thus dropping JDK8-10 runtime support.
> > >
> > > пт, 25 авг. 2023 г. в 12:03, Anton Vinogradov :
> > >
> > > > I looks like you're proposing not migration to 2.11 (because it is
> > > already
> > > > supported), but Java 8-9 support dropping.
> > > >
> > > > On Fri, Aug 25, 2023 at 11:54 AM Peter Ivanov 
> > > wrote:
> > > >
> > > > > Hi, Igniters!
> > > > >
> > > > >
> > > > > I would like to propose the next, if you don't mind me saying,
> > > > > revolutionary step forward in our project: moving Ignite 2.x
> > > compilation
> > > > to
> > > > > JDK11 minimum version.
> > > > > I'd rather not make arguments, pros and cons other that currently
> > exist
> > > > in
> > > > > Java world - you know them better than me. Let's just say that it
> > seems
> > > > > that time has come - consider at least that JDK11 as the LTS
> version
> > is
> > > > > already about 4 and a half years on the go, and Ignite 3.x started
> > from
> > > > > JDK11 right away.
> > > > >
> > > > > This change may possibly require from us additional efforts on
> > > supporting
> > > > > the last version with JDK8 in terms of releasing additional patches
> > and
> > > > > hotfixes a bit longer than usual. However, this is up to the
> > community
> > > to
> > > > > decide.
> > > > >
> > > > > Currently, Apache Ignite 2.x (with Extensions as well) is already
> > > > prepared
> > > > > for being compiled with JDK11 and almost all tests are passing. If
> we
> > > > come
> > > > > to an agreement about this proposal and designate the next version
> > that
> > > > > will become the first to provide JDK11 compiled binaries - I am
> ready
> > > to
> > > > > start the process of updating the TeamCity building project
> > > accordingly.
> > > > >
> > > > >
> > > > > Please, share your thoughts.
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [PROPOSAL] Move Ignite 2.x to JDK11 compilation

[Ivan Daschinsky]

+1. It's time to do it at last.

пт, 25 авг. 2023 г. в 12:06, Peter Ivanov :

> Mostly, yes.
>
> In other words - proposal is about starting shipping Apache Ignite releases
> with JDK11 compiled binaries thus dropping JDK8-10 runtime support.
>
> пт, 25 авг. 2023 г. в 12:03, Anton Vinogradov :
>
> > I looks like you're proposing not migration to 2.11 (because it is
> already
> > supported), but Java 8-9 support dropping.
> >
> > On Fri, Aug 25, 2023 at 11:54 AM Peter Ivanov 
> wrote:
> >
> > > Hi, Igniters!
> > >
> > >
> > > I would like to propose the next, if you don't mind me saying,
> > > revolutionary step forward in our project: moving Ignite 2.x
> compilation
> > to
> > > JDK11 minimum version.
> > > I'd rather not make arguments, pros and cons other that currently exist
> > in
> > > Java world - you know them better than me. Let's just say that it seems
> > > that time has come - consider at least that JDK11 as the LTS version is
> > > already about 4 and a half years on the go, and Ignite 3.x started from
> > > JDK11 right away.
> > >
> > > This change may possibly require from us additional efforts on
> supporting
> > > the last version with JDK8 in terms of releasing additional patches and
> > > hotfixes a bit longer than usual. However, this is up to the community
> to
> > > decide.
> > >
> > > Currently, Apache Ignite 2.x (with Extensions as well) is already
> > prepared
> > > for being compiled with JDK11 and almost all tests are passing. If we
> > come
> > > to an agreement about this proposal and designate the next version that
> > > will become the first to provide JDK11 compiled binaries - I am ready
> to
> > > start the process of updating the TeamCity building project
> accordingly.
> > >
> > >
> > > Please, share your thoughts.
> > >
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Removal of ignite ml module (or moving it to extensions)

[Ivan Daschinsky]

ML Extensions suite is ready and it works, all tests from the main module
and parsers, all examples -- everything works and all green [1].
The green visa has been obtained. So I am going to merge it tomorrow, if
there is no objection.



[1] ---
https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Ml/7438920?hideProblemsFromDependencies=false=false

Re: TX code cleanup (MVCC removal)

[Ivan Daschinsky]

The plan looks good to me. Some of the tests are in the ODBC test suite, so
i can help if needed.

ср, 16 авг. 2023 г. в 16:32, Anton Vinogradov :

> Igniters,
>
> I started the TX code cleanup [1] last month and almost finished with the
> obvious garbage.
> Now, started the code deduplication, I was faced with code overcomplexity
> because of unfinished MVCC.
>
> The community agreed to remove MVCC, but the initial attempt [2] was not
> successful because of the impossibility to get rid of 20k+ lines of the
> code at once.
> So, my proposal is to remove it step by step.
>
> 1) MVCC tests should be removed from the project
> 2) MVCC-related code should be removed from the project by reasonably sized
> commits, checking it does not affect the existing tests.
>
> I'm ready to perform the removal.
>
> Any objections/tips?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-19844
> [2] https://issues.apache.org/jira/browse/IGNITE-13871
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Removal of ignite ml module (or moving it to extensions)

[Ivan Daschinsky]

>> https://issues.apache.org/jira/browse/IGNITE-20216
Also, I've updated dependencies and fixed BLAS issue (tested with intel mkl
blas on ubuntu 22.04)

ср, 16 авг. 2023 г. в 12:11, Ivan Daschinsky :

> I've filed a ticket and created 2 PRs. After tuning of TC I'm going to
> merge both of them, if nobody disagrees with it.
>
> https://issues.apache.org/jira/browse/IGNITE-20216
>
>
>
> пн, 14 авг. 2023 г. в 22:29, Ivan Daschinsky :
>
>> >> * com.github.fommil.netlib:core:1.1.2 - not developed and archived
>> since 2017. Last version released in 2013 [2]
>> Moreover, this version is so outdated and JNI extension was so strangely
>> made (linked to libgfortran3 for example), that native BLAS simply doesn't
>> work.
>> Always fallback option is used (f2jBLAS, and it is also outdated).
>> There is a modern option -- https://github.com/luhenry/netlib, it is
>> used in spark mllib.
>>
>> I have run all tests successfully with it (with few lines changed, of
>> course) using native blas (libopenblas on ubuntu 22.04)
>>
>> So it is possible to state that nobody has run it on native blas. So I
>> have some concerns about existence of prod like installations with Ignite
>> ML module
>>
>> пт, 11 авг. 2023 г. в 13:14, Николай Ижиков :
>>
>>> A few cents to let you know how abandoned ML module is.
>>>
>>> 1. Last valuable commit December 9, 2020 -
>>> https://github.com/apache/ignite/commit/04f6a33851d9f7bd269a09fdc2c74485b1e01a8a
>>>
>>> 2. Dependencies and current versions of them:
>>>
>>>   * com.dropbox.core:dropbox-core-sdk:2.1.1 current version is - 5.4.5
>>> [1]
>>>   * com.github.fommil.netlib:core:1.1.2 - not developed and archived
>>> since 2017. Last version released in 2013 [2]
>>>   * org.apache.commons:commons-rng-core:1.0 current version is 1.5 [3]
>>>   * com.zaxxer:SparseBitSet:1.0 current version is 1.2 [4]
>>>   * ai.catboost:catboost-prediction:0.24 current version is 1.2 [5]
>>>   * ai.h2o:h2o-genmodel:3.26.0.8 current version is 3.42.0.2 [6]
>>>
>>> ML community make a huge step forward since 2020.
>>> So I doubt ML features and tools integrations works as expected nowadays.
>>> Those type of Ignite features(abandoned or supported partially) has to
>>> be in extensions.
>>>
>>> [1] https://github.com/dropbox/dropbox-sdk-java
>>> [2] https://github.com/fommil/netlib-java
>>> [3] https://commons.apache.org/proper/commons-rng/commons-rng-core/
>>> [4] https://github.com/brettwooldridge/SparseBitSet
>>> [5] https://mvnrepository.com/artifact/ai.catboost/catboost-prediction
>>> [6] https://mvnrepository.com/artifact/ai.h2o/h2o-genmodel
>>>
>>>
>>>
>>> > 11 авг. 2023 г., в 12:19, Kseniya Romanova 
>>> написал(а):
>>> >
>>> > As far as I know, the integration was removed from the Tensorflow side.
>>> >
>>> > On Thu, Aug 10, 2023 at 2:04 PM Andrey Mashenkov <
>>> andrey.mashen...@gmail.com>
>>> > wrote:
>>> >
>>> >> Ivan,
>>> >>
>>> >>> Actually, I haven't found any integration with tensorflow in AI code.
>>> >>
>>> >> Ok. You are right.
>>> >> Tensorflow is mentioned in docs: docs/_docs/setup.adoc.
>>> >>
>>> >> Adapters may require compilation time dependencies, but these
>>> dependencies
>>> >> shouldn't be part or release package,
>>> >> regardless whether the ML module is a part of Ignite or extensions.
>>> WDYT?
>>> >>
>>> >> On Thu, Aug 10, 2023 at 1:36 PM Ivan Daschinsky 
>>> >> wrote:
>>> >>
>>> >>> Actually, I haven't found any integration with tensorflow in AI code.
>>> >>> Actually, all integrations are some adapters that allow to load
>>> >> pretrained
>>> >>> models (h2o, catboost etc.)
>>> >>>
>>> >>> чт, 10 авг. 2023 г. в 13:08, Ivan Daschinsky :
>>> >>>
>>> >>>> I am personally for moving to extensions. Alex has already mentioned
>>> >> all
>>> >>>> the reasons why it should be done and all of them are quite
>>> important.
>>> >>>> The module seems to be quite independent and there is no problem to
>>> >> move
>>> >>>> it to ignite-extensions.
>>> >>>> So I am +1 for 

Re: Removal of ignite ml module (or moving it to extensions)

[Ivan Daschinsky]

I've filed a ticket and created 2 PRs. After tuning of TC I'm going to
merge both of them, if nobody disagrees with it.

https://issues.apache.org/jira/browse/IGNITE-20216



пн, 14 авг. 2023 г. в 22:29, Ivan Daschinsky :

> >> * com.github.fommil.netlib:core:1.1.2 - not developed and archived
> since 2017. Last version released in 2013 [2]
> Moreover, this version is so outdated and JNI extension was so strangely
> made (linked to libgfortran3 for example), that native BLAS simply doesn't
> work.
> Always fallback option is used (f2jBLAS, and it is also outdated).
> There is a modern option -- https://github.com/luhenry/netlib, it is used
> in spark mllib.
>
> I have run all tests successfully with it (with few lines changed, of
> course) using native blas (libopenblas on ubuntu 22.04)
>
> So it is possible to state that nobody has run it on native blas. So I
> have some concerns about existence of prod like installations with Ignite
> ML module
>
> пт, 11 авг. 2023 г. в 13:14, Николай Ижиков :
>
>> A few cents to let you know how abandoned ML module is.
>>
>> 1. Last valuable commit December 9, 2020 -
>> https://github.com/apache/ignite/commit/04f6a33851d9f7bd269a09fdc2c74485b1e01a8a
>>
>> 2. Dependencies and current versions of them:
>>
>>   * com.dropbox.core:dropbox-core-sdk:2.1.1 current version is - 5.4.5 [1]
>>   * com.github.fommil.netlib:core:1.1.2 - not developed and archived
>> since 2017. Last version released in 2013 [2]
>>   * org.apache.commons:commons-rng-core:1.0 current version is 1.5 [3]
>>   * com.zaxxer:SparseBitSet:1.0 current version is 1.2 [4]
>>   * ai.catboost:catboost-prediction:0.24 current version is 1.2 [5]
>>   * ai.h2o:h2o-genmodel:3.26.0.8 current version is 3.42.0.2 [6]
>>
>> ML community make a huge step forward since 2020.
>> So I doubt ML features and tools integrations works as expected nowadays.
>> Those type of Ignite features(abandoned or supported partially) has to be
>> in extensions.
>>
>> [1] https://github.com/dropbox/dropbox-sdk-java
>> [2] https://github.com/fommil/netlib-java
>> [3] https://commons.apache.org/proper/commons-rng/commons-rng-core/
>> [4] https://github.com/brettwooldridge/SparseBitSet
>> [5] https://mvnrepository.com/artifact/ai.catboost/catboost-prediction
>> [6] https://mvnrepository.com/artifact/ai.h2o/h2o-genmodel
>>
>>
>>
>> > 11 авг. 2023 г., в 12:19, Kseniya Romanova 
>> написал(а):
>> >
>> > As far as I know, the integration was removed from the Tensorflow side.
>> >
>> > On Thu, Aug 10, 2023 at 2:04 PM Andrey Mashenkov <
>> andrey.mashen...@gmail.com>
>> > wrote:
>> >
>> >> Ivan,
>> >>
>> >>> Actually, I haven't found any integration with tensorflow in AI code.
>> >>
>> >> Ok. You are right.
>> >> Tensorflow is mentioned in docs: docs/_docs/setup.adoc.
>> >>
>> >> Adapters may require compilation time dependencies, but these
>> dependencies
>> >> shouldn't be part or release package,
>> >> regardless whether the ML module is a part of Ignite or extensions.
>> WDYT?
>> >>
>> >> On Thu, Aug 10, 2023 at 1:36 PM Ivan Daschinsky 
>> >> wrote:
>> >>
>> >>> Actually, I haven't found any integration with tensorflow in AI code.
>> >>> Actually, all integrations are some adapters that allow to load
>> >> pretrained
>> >>> models (h2o, catboost etc.)
>> >>>
>> >>> чт, 10 авг. 2023 г. в 13:08, Ivan Daschinsky :
>> >>>
>> >>>> I am personally for moving to extensions. Alex has already mentioned
>> >> all
>> >>>> the reasons why it should be done and all of them are quite
>> important.
>> >>>> The module seems to be quite independent and there is no problem to
>> >> move
>> >>>> it to ignite-extensions.
>> >>>> So I am +1 for moving to ignite-extensions.
>> >>>>
>> >>>>
>> >>>> чт, 10 авг. 2023 г. в 12:45, Kseniya Romanova > >:
>> >>>>
>> >>>>>>
>> >>>>>> do you know anyone who uses it?
>> >>>>>
>> >>>>> I know some teams, who do. At the last Ignite Summit we had a talk
>> >>>>> featuring Ml module (from the Groovy community).
>> >>>>> Anyway, We need here the module maintainer opinion
>> >>>>>  + Alex
>>

Re: Removal of ignite ml module (or moving it to extensions)

[Ivan Daschinsky]

>> * com.github.fommil.netlib:core:1.1.2 - not developed and archived since
2017. Last version released in 2013 [2]
Moreover, this version is so outdated and JNI extension was so strangely
made (linked to libgfortran3 for example), that native BLAS simply doesn't
work.
Always fallback option is used (f2jBLAS, and it is also outdated).
There is a modern option -- https://github.com/luhenry/netlib, it is used
in spark mllib.

I have run all tests successfully with it (with few lines changed, of
course) using native blas (libopenblas on ubuntu 22.04)

So it is possible to state that nobody has run it on native blas. So I have
some concerns about existence of prod like installations with Ignite ML
module

пт, 11 авг. 2023 г. в 13:14, Николай Ижиков :

> A few cents to let you know how abandoned ML module is.
>
> 1. Last valuable commit December 9, 2020 -
> https://github.com/apache/ignite/commit/04f6a33851d9f7bd269a09fdc2c74485b1e01a8a
>
> 2. Dependencies and current versions of them:
>
>   * com.dropbox.core:dropbox-core-sdk:2.1.1 current version is - 5.4.5 [1]
>   * com.github.fommil.netlib:core:1.1.2 - not developed and archived since
> 2017. Last version released in 2013 [2]
>   * org.apache.commons:commons-rng-core:1.0 current version is 1.5 [3]
>   * com.zaxxer:SparseBitSet:1.0 current version is 1.2 [4]
>   * ai.catboost:catboost-prediction:0.24 current version is 1.2 [5]
>   * ai.h2o:h2o-genmodel:3.26.0.8 current version is 3.42.0.2 [6]
>
> ML community make a huge step forward since 2020.
> So I doubt ML features and tools integrations works as expected nowadays.
> Those type of Ignite features(abandoned or supported partially) has to be
> in extensions.
>
> [1] https://github.com/dropbox/dropbox-sdk-java
> [2] https://github.com/fommil/netlib-java
> [3] https://commons.apache.org/proper/commons-rng/commons-rng-core/
> [4] https://github.com/brettwooldridge/SparseBitSet
> [5] https://mvnrepository.com/artifact/ai.catboost/catboost-prediction
> [6] https://mvnrepository.com/artifact/ai.h2o/h2o-genmodel
>
>
>
> > 11 авг. 2023 г., в 12:19, Kseniya Romanova 
> написал(а):
> >
> > As far as I know, the integration was removed from the Tensorflow side.
> >
> > On Thu, Aug 10, 2023 at 2:04 PM Andrey Mashenkov <
> andrey.mashen...@gmail.com>
> > wrote:
> >
> >> Ivan,
> >>
> >>> Actually, I haven't found any integration with tensorflow in AI code.
> >>
> >> Ok. You are right.
> >> Tensorflow is mentioned in docs: docs/_docs/setup.adoc.
> >>
> >> Adapters may require compilation time dependencies, but these
> dependencies
> >> shouldn't be part or release package,
> >> regardless whether the ML module is a part of Ignite or extensions.
> WDYT?
> >>
> >> On Thu, Aug 10, 2023 at 1:36 PM Ivan Daschinsky 
> >> wrote:
> >>
> >>> Actually, I haven't found any integration with tensorflow in AI code.
> >>> Actually, all integrations are some adapters that allow to load
> >> pretrained
> >>> models (h2o, catboost etc.)
> >>>
> >>> чт, 10 авг. 2023 г. в 13:08, Ivan Daschinsky :
> >>>
> >>>> I am personally for moving to extensions. Alex has already mentioned
> >> all
> >>>> the reasons why it should be done and all of them are quite important.
> >>>> The module seems to be quite independent and there is no problem to
> >> move
> >>>> it to ignite-extensions.
> >>>> So I am +1 for moving to ignite-extensions.
> >>>>
> >>>>
> >>>> чт, 10 авг. 2023 г. в 12:45, Kseniya Romanova  >:
> >>>>
> >>>>>>
> >>>>>> do you know anyone who uses it?
> >>>>>
> >>>>> I know some teams, who do. At the last Ignite Summit we had a talk
> >>>>> featuring Ml module (from the Groovy community).
> >>>>> Anyway, We need here the module maintainer opinion
> >>>>>  + Alex
> >>>>>
> >>>>> On Wed, Aug 9, 2023 at 3:38 PM Andrey Mashenkov <
> >>>>> andrey.mashen...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> -1 for removal.
> >>>>>> 0 for relocation
> >>>>>>
> >>>>>> imho, TC resources and module size aren't good arguments for
> >>>>>> removal/moving.
> >>>>>> ML tests could be run nightly.
> >>>>>> ML module contains few integrations (with TensorFlow and other),
> >>

Re: Removal of ignite ml module (or moving it to extensions)

[Ivan Daschinsky]

Actually, I haven't found any integration with tensorflow in AI code.
Actually, all integrations are some adapters that allow to load pretrained
models (h2o, catboost etc.)

чт, 10 авг. 2023 г. в 13:08, Ivan Daschinsky :

> I am personally for moving to extensions. Alex has already mentioned all
> the reasons why it should be done and all of them are quite important.
> The module seems to be quite independent and there is no problem to move
> it to ignite-extensions.
>  So I am +1 for moving to ignite-extensions.
>
>
> чт, 10 авг. 2023 г. в 12:45, Kseniya Romanova :
>
>> >
>> > do you know anyone who uses it?
>>
>> I know some teams, who do. At the last Ignite Summit we had a talk
>> featuring Ml module (from the Groovy community).
>> Anyway, We need here the module maintainer opinion
>>   + Alex
>>
>> On Wed, Aug 9, 2023 at 3:38 PM Andrey Mashenkov <
>> andrey.mashen...@gmail.com>
>> wrote:
>>
>> > -1 for removal.
>> > 0 for relocation
>> >
>> > imho, TC resources and module size aren't good arguments for
>> > removal/moving.
>> > ML tests could be run nightly.
>> > ML module contains few integrations (with TensorFlow and other), these
>> > optional integrations are wighty and could be moved to extension,
>> > but core functionality still can be left untouched if it is highly
>> coupled
>> > with core Ignite and moving to extension is hard.
>> >
>> >
>> > On Wed, Aug 9, 2023 at 3:22 PM Anton Vinogradov  wrote:
>> >
>> > > +1 to relocation
>> > >
>> > > On Wed, Aug 9, 2023 at 3:09 PM Alex Plehanov > >
>> > > wrote:
>> > >
>> > > > Pavel, do you know anyone who uses it?
>> > > >
>> > > > Looks like it isn't used at all (no questions on mail lists, no
>> > > > tickets), but we spend developers time to build module with every
>> > > > Ignite rebuild, we spend users traffic to download module (ML with
>> > > > dependencies takes about 1/4 of our binary release package size) and
>> > > > we spend team-city resources to test module.
>> > > >
>> > > > +1 for removing or moving to extensions.
>> > > >
>> > > > ср, 9 авг. 2023 г. в 14:19, Pavel Tupitsyn :
>> > > > >
>> > > > > Does it have any outstanding issues? A stable and useful module
>> > should
>> > > > not
>> > > > > be removed just because it does not evolve.
>> > > > >
>> > > > > On Wed, Aug 9, 2023 at 1:46 PM Ivan Daschinsky <
>> ivanda...@apache.org
>> > >
>> > > > wrote:
>> > > > >
>> > > > > > Igniters, seems that this module is completely abandoned for
>> more
>> > > than
>> > > > 2
>> > > > > > years. But it is enormous and it seems that nobody wants to take
>> > care
>> > > > of
>> > > > > > it. I suggest just removing it or moving it to extensions (as
>> > > option).
>> > > > > > WDYT?
>> > > > > >
>> > > >
>> > >
>> >
>> >
>> > --
>> > Best regards,
>> > Andrey V. Mashenkov
>> >
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Removal of ignite ml module (or moving it to extensions)

[Ivan Daschinsky]

I am personally for moving to extensions. Alex has already mentioned all
the reasons why it should be done and all of them are quite important.
The module seems to be quite independent and there is no problem to move it
to ignite-extensions.
 So I am +1 for moving to ignite-extensions.


чт, 10 авг. 2023 г. в 12:45, Kseniya Romanova :

> >
> > do you know anyone who uses it?
>
> I know some teams, who do. At the last Ignite Summit we had a talk
> featuring Ml module (from the Groovy community).
> Anyway, We need here the module maintainer opinion
>   + Alex
>
> On Wed, Aug 9, 2023 at 3:38 PM Andrey Mashenkov <
> andrey.mashen...@gmail.com>
> wrote:
>
> > -1 for removal.
> > 0 for relocation
> >
> > imho, TC resources and module size aren't good arguments for
> > removal/moving.
> > ML tests could be run nightly.
> > ML module contains few integrations (with TensorFlow and other), these
> > optional integrations are wighty and could be moved to extension,
> > but core functionality still can be left untouched if it is highly
> coupled
> > with core Ignite and moving to extension is hard.
> >
> >
> > On Wed, Aug 9, 2023 at 3:22 PM Anton Vinogradov  wrote:
> >
> > > +1 to relocation
> > >
> > > On Wed, Aug 9, 2023 at 3:09 PM Alex Plehanov 
> > > wrote:
> > >
> > > > Pavel, do you know anyone who uses it?
> > > >
> > > > Looks like it isn't used at all (no questions on mail lists, no
> > > > tickets), but we spend developers time to build module with every
> > > > Ignite rebuild, we spend users traffic to download module (ML with
> > > > dependencies takes about 1/4 of our binary release package size) and
> > > > we spend team-city resources to test module.
> > > >
> > > > +1 for removing or moving to extensions.
> > > >
> > > > ср, 9 авг. 2023 г. в 14:19, Pavel Tupitsyn :
> > > > >
> > > > > Does it have any outstanding issues? A stable and useful module
> > should
> > > > not
> > > > > be removed just because it does not evolve.
> > > > >
> > > > > On Wed, Aug 9, 2023 at 1:46 PM Ivan Daschinsky <
> ivanda...@apache.org
> > >
> > > > wrote:
> > > > >
> > > > > > Igniters, seems that this module is completely abandoned for more
> > > than
> > > > 2
> > > > > > years. But it is enormous and it seems that nobody wants to take
> > care
> > > > of
> > > > > > it. I suggest just removing it or moving it to extensions (as
> > > option).
> > > > > > WDYT?
> > > > > >
> > > >
> > >
> >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Removal of ignite ml module (or moving it to extensions)

[Ivan Daschinsky]

Igniters, seems that this module is completely abandoned for more than 2
years. But it is enormous and it seems that nobody wants to take care of
it. I suggest just removing it or moving it to extensions (as option). WDYT?

Re: IgniteTxStateImpl's non-threadsafe fields may cause crashes and/or data loss

[Ivan Daschinsky]

>> Tx processing is supposed to be thread bound by hashing the version to a
partition
This invariant is violated in many places. The most notorious example is tx
recovery.

Another example: I just added an assertion that checks tId of a creator
thread with tId of an accessor thread.
TxMultiCacheAsyncOpsTest fails immediately on processing of a tx prepare
request. Looks like a big issue, IMO


пт, 19 мая 2023 г. в 19:11, Alexei Scherbakov :

> Tx processing is supposed to be thread bound by hashing the version to a
> partition, see methods like [1]
> If for some cases this invariant is broken, this should be fixed.
>
> [1]
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareRequest#partition
>
> пт, 19 мая 2023 г. в 15:57, Anton Vinogradov :
>
> > Igniters,
> >
> > My team was faced with node failure [1] because of non-threadsafe
> > collections usage.
> >
> > IgniteTxStateImpl's fields
> > - activeCacheIds
> > - txMap
> > are not thread safe, but are widely used from different threads without
> the
> > proper sync.
> >
> > The main question is ... why?
> >
> > According to the research, we have no guarantee that tx will be processed
> > at the single thread.
> > It may be processed at the several! threads at the striped pool and at
> the
> > tx recovery thread as well.
> >
> > Thread at the striped pool will be selected by the message's partition()
> > method, which can be calculated like this:
> > - return keys != null && !keys.isEmpty() ? keys.get(0).partition() : -1;
> > - return U.safeAbs(version().hashCode());
> > - ...,
> > so, no guarantee it is processed at the same thread (proven by tests).
> >
> > Seems, we MAY lose the data.
> > For example, ignoring some or all keys from txMap at commit.
> >
> > If anyone knows why this is not a problem (I mean sync lack, not data
> loss)
> > or how to fix this properly, please give me a hint, or correct my
> > conclusions if necessary.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-19445
> >
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [VOTE] Release Apache Ignite 2.15.0 RC0

[Ivan Daschinsky]

+1 (binding)

Checked signatures and hashsums.

Checked C++ compilation and examples on linux (ubuntu 22.04) and windows
(win10, vs 2017).

Checked ODBC on linux (ubuntu 22.04, built from source) and windows (built
from source and from installer, both 32 and 64 bit) using python and pyodbc

Checked ODBC with H2 and CALCITE query engines.

пн, 1 мая 2023 г. в 22:07, Ilya Shishkov :

> + 1
>
> Started 2 node in-memory cluster: first node from binary distribution,
> second one from debian package.
> Started and successfully connected application, based on spring-data
> extension examples, but with Ignite dependencies from the staging.
>
> сб, 29 апр. 2023 г. в 10:17, Maxim Muzafarov :
> >
> > +1
> >
> > On Fri, 28 Apr 2023 at 09:54, Vladimir Steshin 
> wrote:
> > >
> > > + 1
> > >
> > > 26.04.2023 22:51, Alex Plehanov пишет:
> > > > Dear Community,
> > > >
> > > > The release candidate is ready.
> > > >
> > > > I have uploaded release candidate to
> > > > https://dist.apache.org/repos/dist/dev/ignite/2.15.0-rc0/
> > > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.15.0-rc0/
> > > >
> > > > The following staging can be used for testing:
> > > >
> https://repository.apache.org/content/repositories/orgapacheignite-1558/
> > > >
> > > > Tag name is 2.15.0-rc0:
> > > >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.15.0-rc0
> > > >
> > > > 2.15.0 most important changes:
> > > > * Implemented incremental snapshots.
> > > > * Java thin client improvements (logging, connections balancing,
> events
> > > > listening, endpoints discovery)
> > > > * Calcite based SQL engine improvements (memory quotas, index scans
> > > > optimisations).
> > > > * Reworked permission management for system tasks.
> > > > * Removed deprecated functionality (daemon nodes, visorcmd, legacy
> JMX
> > > > beans).
> > > >
> > > > RELEASE NOTES:
> > > >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.15
> > > >
> > > > Complete list of resolved issues:
> > > >
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20'Ignite'%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20('2.15'))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20('CLOSED'%2C%20'RESOLVED')%20AND%20resolution%20in(Fixed%2C%20Done%2C%20Implemented%2C%20Delivered)%20ORDER%20BY%20priority
> > > > <
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.15%27))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20AND%20resolution%20in(Fixed%2C%20Done%2C%20Implemented%2C%20Delivered)%20ORDER%20BY%20priority
> >
> > > >
> > > >
> > > > DEVNOTES
> > > >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.15
> > > >
> > > > The vote is formal, see voting guidelines
> https://www.apache.org/foundation/
> > > > voting.html
> > > >
> > > > +1 - to accept Apache Ignite 2.15.0-rc0
> > > > 0 - don't care either way
> > > > -1 - DO NOT accept Apache Ignite Ignite 2.15.0-rc0 (explain why)
> > > >
> > > > See notes on how to verify release here
> > > > https://www.apache.org/info/verification.html
> > > > and
> > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> > > >
> > > > This vote will be open till Tue May 2, 2023, 07:00 UTC.
> > > >
> https://www.timeanddate.com/countdown/vote?iso=20230502T07=0=VOTE+on+the+Apache+Ignite+Release+2.15.0+RC0=sanserif
> > > >
>


-- 
Sincerely yours, Ivan Daschinskiy

[ANNOUNCE] Release pyignite-0.6.1

[Ivan Daschinsky]

Hi, Igniters!
The release was releases and uploaded to pypi 02/17/22
Sorry for the late announcement

Re: [VOTE][RESULT] Release pyignite 0.6.1.rc1

[Ivan Daschinsky]

Sorry, the mistake -- pyignite 0.6.1.rc0

пт, 17 февр. 2023 г. в 18:04, Ivan Daschinsky :

>
> 5 (4 binding) +1 votes (Nickolay Izhikov,  Pavel Tupitsyn, Vladimir
> Steshin, Slava Koptilin, Maxim Muzafarov)
> No 0 votes
> No -1 votes
>
> Therefore, the release is accepted unanimously.
> Release binaries will be uploaded soon. The release will be announced soon.
>
> Thank you all!
>


-- 
Sincerely yours, Ivan Daschinskiy

[VOTE][RESULT] Release pyignite 0.6.1.rc1

[Ivan Daschinsky]

5 (4 binding) +1 votes (Nickolay Izhikov,  Pavel Tupitsyn, Vladimir
Steshin, Slava Koptilin, Maxim Muzafarov)
No 0 votes
No -1 votes

Therefore, the release is accepted unanimously.
Release binaries will be uploaded soon. The release will be announced soon.

Thank you all!

Re: [VOTE] Release bug fix release pyignite-0.6.1-rc0

[Ivan Daschinsky]

The vote is closed. The results will be announced soon.

ср, 15 февр. 2023 г. в 14:10, Maxim Muzafarov :

> +1
>
> On Wed, 15 Feb 2023 at 11:17, Вячеслав Коптилин
>  wrote:
> >
> > +1
> >
> >
> > ср, 15 февр. 2023 г. в 10:21, Ivan Daschinsky :
> >
> > > Dear Igniters!
> > >
> > > This is a patch release that contains an important fix for users of
> > > pyignite
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-18788
> > >
> > >
> > > Release candidate binaries for subj are uploaded and ready for vote
> > > You can find them here:
> > > https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.6.1-rc0
> > >
> > > If you follow the link above, you will find source packages (*.tar.gz
> and
> > > *.zip)
> > > and binary packages (wheels) for windows (amd64), linux (x86_64) amd
> mac os
> > > (x86_64)
> > > for pythons 37, 38, 39, 310 and 311. Also, there are sha512 and gpg
> > > signatures.
> > > Code signing keys can be found here --
> https://downloads.apache.org/ignite
> > > /KEYS
> > > Here you can find instructions how to verify packages
> > > https://www.apache.org/info/verification.html
> > >
> > > You can install binary package for specific version of python using pip
> > > For example do this on linux for python 3.8
> > > >> pip install
> > >
> > >
> pyignite-0.6.1-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl
> > >
> > > You can build and install package from source using this command:
> > > >> pip install pyignite-0.6.1.zip
> > > You can build wheel on your platform using this command:
> > > >> pip wheel --no-deps pyignite-0.6.1.zip
> > >
> > > For building C module, you should have python headers and C compiler
> > > installed.
> > > (i.e. for ubuntu sudo apt install build-essential python3-dev)
> > > In Mac OS X xcode-tools and python from homebrew are the best option.
> > >
> > > In order to check whether C module works, use following:
> > > >> from pyignite import _cutils
> > > >> print(_cutils.hashcode('test'))
> > > >> 3556498
> > >
> > > You can find documentation here:
> > >
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.1.rc0/
> > >
> > > You can find examples here (to check them, you should start ignite
> > > locally):
> > >
> > >
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.1.rc0/examples.html
> > > Also, examples can be found in source archive in examples subfolder.
> > > docker-compose.yml is supplied in order to start ignite quickly. (Use
> > > `docker-compose up -d` to start 3 nodes cluster and `docker-compose
> > > down` to shut down it)
> > >
> > > Release notes:
> > >
> > >
> https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=blob;f=RELEASE_NOTES.txt;h=86448e9ce51d7223ac49cf4f95da70d3d365e8c1;hb=0d86f44e86270f4d578afbce41aa2d6c424d2615
> > >
> > > Git release tag was created:
> > >
> > >
> https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=tag;h=b0ce094d7a2db3fb07471be7b37ff9edab4180a8
> > >
> > > The vote is formal, see voting guidelines
> > > https://www.apache.org/foundation/voting.html
> > >
> > > +1 - to accept pyignite-0.6.1-rc0
> > > 0 - don't care either way
> > > -1 - DO NOT accept pyignite-0.6.1-rc0
> > >
> > > The vote finishes at 02/17/2021 15:00 UTC
> > >
> > > --
> > > Sincerely yours, Ivan Daschinskiy
> > >
>


-- 
Sincerely yours, Ivan Daschinskiy

[VOTE] Release bug fix release pyignite-0.6.1-rc0

[Ivan Daschinsky]

Dear Igniters!

This is a patch release that contains an important fix for users of
pyignite

https://issues.apache.org/jira/browse/IGNITE-18788


Release candidate binaries for subj are uploaded and ready for vote
You can find them here:
https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.6.1-rc0

If you follow the link above, you will find source packages (*.tar.gz and
*.zip)
and binary packages (wheels) for windows (amd64), linux (x86_64) amd mac os
(x86_64)
for pythons 37, 38, 39, 310 and 311. Also, there are sha512 and gpg
signatures.
Code signing keys can be found here -- https://downloads.apache.org/ignite
/KEYS
Here you can find instructions how to verify packages
https://www.apache.org/info/verification.html

You can install binary package for specific version of python using pip
For example do this on linux for python 3.8
>> pip install
pyignite-0.6.1-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl

You can build and install package from source using this command:
>> pip install pyignite-0.6.1.zip
You can build wheel on your platform using this command:
>> pip wheel --no-deps pyignite-0.6.1.zip

For building C module, you should have python headers and C compiler
installed.
(i.e. for ubuntu sudo apt install build-essential python3-dev)
In Mac OS X xcode-tools and python from homebrew are the best option.

In order to check whether C module works, use following:
>> from pyignite import _cutils
>> print(_cutils.hashcode('test'))
>> 3556498

You can find documentation here:
https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.1.rc0/

You can find examples here (to check them, you should start ignite locally):
https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.1.rc0/examples.html
Also, examples can be found in source archive in examples subfolder.
docker-compose.yml is supplied in order to start ignite quickly. (Use
`docker-compose up -d` to start 3 nodes cluster and `docker-compose
down` to shut down it)

Release notes:
https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=blob;f=RELEASE_NOTES.txt;h=86448e9ce51d7223ac49cf4f95da70d3d365e8c1;hb=0d86f44e86270f4d578afbce41aa2d6c424d2615

Git release tag was created:
https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=tag;h=b0ce094d7a2db3fb07471be7b37ff9edab4180a8

The vote is formal, see voting guidelines
https://www.apache.org/foundation/voting.html

+1 - to accept pyignite-0.6.1-rc0
0 - don't care either way
-1 - DO NOT accept pyignite-0.6.1-rc0

The vote finishes at 02/17/2021 15:00 UTC

-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSSION] Java thin client connection balancing

[Ivan Daschinsky]

Alex, I agree with your proposal. It is ok to start scanning servers
firstly using the same default port, then continue with subsequent ports
within range.

пт, 20 янв. 2023 г. в 10:47, Alex Plehanov :

> Pavel,
>
> But in this case connections still will be unbalanced for disabled
> partition awareness. What if we add some kind of heuristic for choosing the
> first channel, for example, sort addresses by port and select random from
> the set of addresses with the same (minimal) port? This will cover most of
> the production cases, since several nodes on the same host can mostly be
> found in test environments.
>
> пт, 20 янв. 2023 г. в 09:43, Pavel Tupitsyn :
>
> > Alex, I agree with proposals 2 and 3.
> >
> > However, IGNITE-15807 is not about random server, it is about random port
> > on the same server.
> > As I understand, the scenario is: we know that the server is at address
> > a.b.c.d,
> > but we are not sure which port will be chosen,
> > because ClientConnectorConfiguration has a portRange.
> > Most likely it is the first port in range, so we should try that first.
> >
> > On Thu, Jan 19, 2023 at 9:36 PM Alex Plehanov 
> > wrote:
> >
> > > Hello, Igniters!
> > >
> > > I've found that since Ignite 2.12 java thin client always connects to
> the
> > > first address from the provided addresses list. In typical
> configuration
> > > this leads to overloading one server node and underloading other server
> > > nodes. Even when partition awareness is enabled some types of
> operations
> > > still use default connection. This behaviour was introduced by [1].
> > Before
> > > this patch default channel was chosen randomly.
> > > I've read comments in the ticket, but I'm not sure I quite understand
> the
> > > described use case ("few nodes always exist, but other nodes are
> > > added/removed based on the load") and how it was intended to be
> resolved
> > by
> > > this fix. But certainly, it's not the best way to resolve this problem.
> > > Perhaps, cluster discovery will be better for this case? We already
> have
> > it
> > > in protocol and implementation for the .NET thin client, so it can be
> > > implemented for the java thin client too.
> > >
> > > My proposals:
> > > 1. Revert the patch (use random default node)
> > > 2. Implement cluster discovery for java thin client
> > > 3. If partition awareness is enabled - use random open channel instead
> of
> > > default channel for operation which can't be mapped to certain node (to
> > > even better workload distribution to server nodes)
> > >
> > > [1]: https://issues.apache.org/jira/browse/IGNITE-15807
> > >
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSSION] Removal of ignitevisorcmd

[Ivan Daschinsky]

+1  This module seems to be completely abandoned

чт, 1 дек. 2022 г., 00:46 Ilya Kasnacheev :

> Hello!
>
> Let's go ahead and remove what we don't use. Most of that stuff is deep
> legacy, even if it contains some rare gems of functionality that nobody
> knows how to use anymore.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 30 нояб. 2022 г. в 20:12, Nikolay Izhikov :
>
> > Hello, Igniters.
> >
> > There are legacy modules - visor-console, visor-plugins,
> visor-console-2.10
> > Looks like that modules are not  evolving by community and barely used by
> > the Ignite users.
> >
> > I propose to remove it completely.
> > There are IEP [1] for this
> >
> > It seems that removal of visor modules allow to us to remove another
> legacy
> > code from Ignite codebase:
> >
> > * support of daemon nodes.
> > * GridClient and related classes.
> >
> > What do you think?
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=217392419
> >
>

Re: [ANNOUNCE] Apache Ignite 3.0.0-beta1 is released

[Ivan Daschinsky]

Cool, the first beta is a real achievement! Congrats!

пн, 21 нояб. 2022 г. в 18:20, Igor Sapego :

> Congrats, guys!
>
> Best Regards,
> Igor
>
>
> On Thu, Nov 17, 2022 at 4:39 PM Вячеслав Коптилин <
> slava.kopti...@gmail.com>
> wrote:
>
> > Dear Igniters,
> >
> > I'm happy to announce that the 1st beta version of Ignite 3 is out!
> >
> > On top of the functionality that was previously released, Beta 5 adds the
> > following major features:
> > - RPM and DEB packages: simplified installation and node management with
> > system services.
> > - Client's Partition Awareness: Clients are now aware of data
> distribution
> > over the cluster nodes which helps avoid additional network transmissions
> > and lowers operations latency.
> > - C++ client:  Basic C++ client, able to perform operations on data.
> > - Autogenerated values: now a function can be specified as a default
> value
> > generator during a table creation. Currently only gen_random_uuid is
> > supported.
> > - SQL Transactions.
> > - Transactional Protocol: improved locking model, multi-version based
> > lock-free read-only transactions.
> > - Storage: A number of improvements to memory-only and on-disk engines
> > based on Page Memory.
> > - Indexes: Basic functionality, hash and sorted indexes.
> > - Client logging: A LoggerFactory may be provided during client creation
> to
> > specify a custom logger for logs generated by the client.
> > - Metrics framework.
> >
> > Code examples have been added for the new features, you can check them
> out
> > https://github.com/apache/ignite-3/tree/ignite-3.0.0-beta1/examples
> >
> > If there are any questions, issues, or thoughts, please do not hesitate
> to
> > reply to this email. Ignite Community is welcoming any feedback and will
> > consider it in future development.
> >
> > Thanks,
> > S.
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

[ANNOUNCE] Apache IGNITE python thin client (pyignite) 0.6.0 have been released

[Ivan Daschinsky]

The Apache Ignite Community is pleased to announce the release of
Apache IGNITE python thin client (pyignite) 0.6.0.

This new release is mostly the maintenance one. However, there are some new
important features and fixes:

1. Fixed non-intuitive automatically setting of flag use_ssl when the
authentication is enabled
2. Added timeout support for cache operations in the async client.
3. Fixed incorrect result setting of already completed futures in async
connection implementation

For the full list of changes, you can look at the RELEASE_NOTES:
https://ignite.apache.org/releases/pyignite/0.6.0/release_notes.html

You can install this version using pip
>> pip install pyignite=0.6.0

Alternatively, you can download sources and binary packages (wheels) from
here:
https://dist.apache.org/repos/dist/release/ignite/pyignite/0.6.0/

Please let us know if you have any problems
https://ignite.apache.org/community/resources.html#ask

Regards,
Ivan Daschinsky on behalf of the Apache Ignite community.

[VOTE] [RESULT] Release pyignite 0.6.0.rc1

[Ivan Daschinsky]

Dear Igniters!

Vote is closed, the result is:

7 (4 binding) +1 votes (Igor Sapego, Sergey Korotkov, Zhenya Stanilovsky,
Ivan Daschinsky, Ilya Shishkov, Anton Vinogradov, Maxim Muzafarov)
No 0 votes
No -1 votes

Therefore, the release is accepted unanimously.
Release binaries will be uploaded soon. The release will be announced soon.

Thank you all!

Re: [VOTE] Release pyignite 0.6.0.rc1

[Ivan Daschinsky]

+1 (binding) Checked signature, hashsums, checked client on all 5 pythons
on all available platforms (mac x86_64, ubuntu x86_84 and windows 10
x86_64).
Checked docs (readthedocs).

вт, 15 нояб. 2022 г. в 09:10, Zhenya Stanilovsky :

>
> +1, thanks Ivan !
>
>
> >Dear Igniters!
> >
> >Release candidate binaries for subj are uploaded and ready for vote
> >You can find them here:
> >https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.6.0.rc1
> >
> >If you follow the link above, you will find source packages (*.zip)
> >and binary packages (wheels) for windows (amd64), mac os x (amd64) and
> >linux (x86_64)
> >for pythons 37, 38, 39, 310 and 311. Also, there are sha512 and gpg
> >signatures.
> >Code signing keys can be found here --
> >https://downloads.apache.org/ignite/KEYS
> >Here you can find instructions how to verify packages
> >https://www.apache.org/info/verification.html
> >
> >You can install binary package for specific version of python using pip
> >For example do this on linux for python 3.8
> >>> pip
> >install
> pyignite-0.6.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl
> >
> >You can build and install package from source using this command:
> >>> pip install pyignite-0.6.0.zip
> >You can build wheel on your platform using this command:
> >>> pip wheel --no-deps pyignite-0.6.0.zip
> >
> >For building C module, you should have python headers and C compiler
> >installed.
> >(i.e. for ubuntu sudo apt install build-essential python3-dev)
> >In Mac OS X xcode-tools and python from homebrew are the best option.
> >
> >In order to check whether C module works, use following:
> >>> from pyignite import _cutils
> >>> print(_cutils.hashcode('test'))
> >>> 3556498
> >
> >You can find documentation here:
> >https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc1/
> >
> >You can find examples here (to check them, you should start ignite
> locally):
> >
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc0/examples.html
> >Also, examples can be found in source archive in examples subfolder.
> >docker-compose.yml is supplied in order to start ignite quickly. (Use
> >`docker-compose up -d` to start 3 nodes cluster and `docker-compose
> >down` to shut down it)
> >
> >Release notes:
> >
> https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=995bda81780402116e89d76523949da88136f260
> >
> >Git release tag was created:
> >
> https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=tag;h=ea3f180a0300abf25c992ed8c241defdc2b4bd4b
> >
> >The vote is formal, see voting guidelines
> >https://www.apache.org/foundation/voting.html
> >
> >+1 - to accept pyignite-0.6.0.rc0
> >0 - don't care either way
> >-1 - DO NOT accept pyignite-0.6.0.rc0
> >
> >The vote finishes at 11/15/2022 15:00 UTC
>
>
>
>

Re: [VOTE] Release pyignite 0.6.0.rc1

[Ivan Daschinsky]

>>
https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc0/examples.html
https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc1/examples.html

пн, 14 нояб. 2022 г. в 16:21, Ivan Daschinsky :

> Dear Igniters!
>
> Release candidate binaries for subj are uploaded and ready for vote
> You can find them here:
> https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.6.0.rc1
>
> If you follow the link above, you will find source packages (*.zip)
> and binary packages (wheels) for windows (amd64), mac os x (amd64) and
> linux (x86_64)
> for pythons 37, 38, 39, 310 and 311. Also, there are sha512 and gpg
> signatures.
> Code signing keys can be found here --
> https://downloads.apache.org/ignite/KEYS
> Here you can find instructions how to verify packages
> https://www.apache.org/info/verification.html
>
> You can install binary package for specific version of python using pip
> For example do this on linux for python 3.8
> >> pip
> install 
> pyignite-0.6.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl
>
> You can build and install package from source using this command:
> >> pip install pyignite-0.6.0.zip
> You can build wheel on your platform using this command:
> >> pip wheel --no-deps pyignite-0.6.0.zip
>
> For building C module, you should have python headers and C compiler
> installed.
> (i.e. for ubuntu sudo apt install build-essential python3-dev)
> In Mac OS X xcode-tools and python from homebrew are the best option.
>
> In order to check whether C module works, use following:
> >> from pyignite import _cutils
> >> print(_cutils.hashcode('test'))
> >> 3556498
>
> You can find documentation here:
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc1/
>
> You can find examples here (to check them, you should start ignite
> locally):
>
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc0/examples.html
> Also, examples can be found in source archive in examples subfolder.
> docker-compose.yml is supplied in order to start ignite quickly. (Use
> `docker-compose up -d` to start 3 nodes cluster and `docker-compose
> down` to shut down it)
>
> Release notes:
>
> https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=995bda81780402116e89d76523949da88136f260
>
> Git release tag was created:
>
> https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=tag;h=ea3f180a0300abf25c992ed8c241defdc2b4bd4b
>
> The vote is formal, see voting guidelines
> https://www.apache.org/foundation/voting.html
>
> +1 - to accept pyignite-0.6.0.rc0
> 0 - don't care either way
> -1 - DO NOT accept pyignite-0.6.0.rc0
>
> The vote finishes at 11/15/2022 15:00 UTC
>

[VOTE] Release pyignite 0.6.0.rc1

[Ivan Daschinsky]

Dear Igniters!

Release candidate binaries for subj are uploaded and ready for vote
You can find them here:
https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.6.0.rc1

If you follow the link above, you will find source packages (*.zip)
and binary packages (wheels) for windows (amd64), mac os x (amd64) and
linux (x86_64)
for pythons 37, 38, 39, 310 and 311. Also, there are sha512 and gpg
signatures.
Code signing keys can be found here --
https://downloads.apache.org/ignite/KEYS
Here you can find instructions how to verify packages
https://www.apache.org/info/verification.html

You can install binary package for specific version of python using pip
For example do this on linux for python 3.8
>> pip
install 
pyignite-0.6.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl

You can build and install package from source using this command:
>> pip install pyignite-0.6.0.zip
You can build wheel on your platform using this command:
>> pip wheel --no-deps pyignite-0.6.0.zip

For building C module, you should have python headers and C compiler
installed.
(i.e. for ubuntu sudo apt install build-essential python3-dev)
In Mac OS X xcode-tools and python from homebrew are the best option.

In order to check whether C module works, use following:
>> from pyignite import _cutils
>> print(_cutils.hashcode('test'))
>> 3556498

You can find documentation here:
https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc1/

You can find examples here (to check them, you should start ignite locally):
https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc0/examples.html
Also, examples can be found in source archive in examples subfolder.
docker-compose.yml is supplied in order to start ignite quickly. (Use
`docker-compose up -d` to start 3 nodes cluster and `docker-compose
down` to shut down it)

Release notes:
https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=995bda81780402116e89d76523949da88136f260

Git release tag was created:
https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=tag;h=ea3f180a0300abf25c992ed8c241defdc2b4bd4b

The vote is formal, see voting guidelines
https://www.apache.org/foundation/voting.html

+1 - to accept pyignite-0.6.0.rc0
0 - don't care either way
-1 - DO NOT accept pyignite-0.6.0.rc0

The vote finishes at 11/15/2022 15:00 UTC

Re: [VOTE] Release pyignite 0.6.0.rc0

[Ivan Daschinsky]

Ok, I've just fixed these issues. So I decided to cancel the vote. New vote
will be announced soon as I'll have uploaded artifacts.

пн, 14 нояб. 2022 г. в 14:50, Ivan Daschinsky :

> Great catch, especially the second one.
>
> Seems that it is a good idea to cancel the vote and create the rc1 vote
>
> пн, 14 нояб. 2022 г. в 14:25, Sergey Korotkov :
>
>> Hi Ivan,
>>
>> I have noticed two issues:
>>
>> 1. Typo in the release notes file:
>>
>> Fixed non-intuitive automatically setting of flag use_ssl *whet* the
>> authentication is enabled.
>>
>> 2. The .whl package contains several test python files are not supposed
>> to be included:
>>
>>  5936  Defl:N 2126  64% 2022-11-11 13:11 8ae223e4 tests/util.py
>>  1587  Defl:N  815  49% 2022-11-11 13:11 70eacc2f
>> tests/test_examples.py
>>  4577  Defl:N 1556  66% 2022-11-11 13:11 bdddf0c1
>> tests/test_cutils.py
>>  2571  Defl:N   57% 2022-11-11 13:11 c0d7dbdf
>> tests/conftest.py
>>   782  Defl:N      452  42% 2022-11-11 13:11 d3a45643
>> tests/__init__.py
>>
>> Thanks,
>>
>> --
>>
>> Sergey Korotkov
>>
>>
>> On 11.11.2022 20:40, Ivan Daschinsky wrote:
>> > Dear Igniters!
>> >
>> > Release candidate binaries for subj are uploaded and ready for vote
>> > You can find them here:
>> > https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.6.0.rc0
>> >
>> > If you follow the link above, you will find source packages (*.zip)
>> > and binary packages (wheels) for windows (amd64), mac os x (amd64) and
>> > linux (x86_64)
>> > for pythons 37, 38, 39, 310 and 311. Also, there are sha512 and gpg
>> > signatures.
>> > Code signing keys can be found here --
>> > https://downloads.apache.org/ignite/KEYS
>> > Here you can find instructions how to verify packages
>> > https://www.apache.org/info/verification.html
>> >
>> > You can install binary package for specific version of python using pip
>> > For example do this on linux for python 3.8
>> >>> pip
>> > install
>> pyignite-0.6.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl
>> >
>> > You can build and install package from source using this command:
>> >>> pip install pyignite-0.6.0.zip
>> > You can build wheel on your platform using this command:
>> >>> pip wheel --no-deps pyignite-0.6.0.zip
>> > For building C module, you should have python headers and C compiler
>> > installed.
>> > (i.e. for ubuntu sudo apt install build-essential python3-dev)
>> > In Mac OS X xcode-tools and python from homebrew are the best option.
>> >
>> > In order to check whether C module works, use following:
>> >>> from pyignite import _cutils
>> >>> print(_cutils.hashcode('test'))
>> >>> 3556498
>> > You can find documentation here:
>> >
>> https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc0/
>> >
>> > You can find examples here (to check them, you should start ignite
>> locally):
>> >
>> https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc0/examples.html
>> > Also, examples can be found in source archive in examples subfolder.
>> > docker-compose.yml is supplied in order to start ignite quickly. (Use
>> > `docker-compose up -d` to start 3 nodes cluster and `docker-compose
>> > down` to shut down it)
>> >
>> > Release notes:
>> >
>> https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=a0600047e7b29fc23350f77d4b087cfb55032d72
>> >
>> > Git release tag was created:
>> >
>> https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=commit;h=a0600047e7b29fc23350f77d4b087cfb55032d72
>> >
>> > The vote is formal, see voting guidelines
>> > https://www.apache.org/foundation/voting.html
>> >
>> > +1 - to accept pyignite-0.6.0.rc0
>> > 0 - don't care either way
>> > -1 - DO NOT accept pyignite-0.6.0.rc0
>> >
>> > The vote finishes at 11/15/2022 15:00 UTC
>> >
>>
>

Re: [VOTE] Release pyignite 0.6.0.rc0

[Ivan Daschinsky]

Great catch, especially the second one.

Seems that it is a good idea to cancel the vote and create the rc1 vote

пн, 14 нояб. 2022 г. в 14:25, Sergey Korotkov :

> Hi Ivan,
>
> I have noticed two issues:
>
> 1. Typo in the release notes file:
>
> Fixed non-intuitive automatically setting of flag use_ssl *whet* the
> authentication is enabled.
>
> 2. The .whl package contains several test python files are not supposed
> to be included:
>
>  5936  Defl:N 2126  64% 2022-11-11 13:11 8ae223e4 tests/util.py
>  1587  Defl:N  815  49% 2022-11-11 13:11 70eacc2f
> tests/test_examples.py
>  4577  Defl:N 1556  66% 2022-11-11 13:11 bdddf0c1
> tests/test_cutils.py
>  2571  Defl:N   57% 2022-11-11 13:11 c0d7dbdf tests/conftest.py
>   782  Defl:N  452  42% 2022-11-11 13:11 d3a45643 tests/__init__.py
>
> Thanks,
>
> --
>
> Sergey Korotkov
>
>
> On 11.11.2022 20:40, Ivan Daschinsky wrote:
> > Dear Igniters!
> >
> > Release candidate binaries for subj are uploaded and ready for vote
> > You can find them here:
> > https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.6.0.rc0
> >
> > If you follow the link above, you will find source packages (*.zip)
> > and binary packages (wheels) for windows (amd64), mac os x (amd64) and
> > linux (x86_64)
> > for pythons 37, 38, 39, 310 and 311. Also, there are sha512 and gpg
> > signatures.
> > Code signing keys can be found here --
> > https://downloads.apache.org/ignite/KEYS
> > Here you can find instructions how to verify packages
> > https://www.apache.org/info/verification.html
> >
> > You can install binary package for specific version of python using pip
> > For example do this on linux for python 3.8
> >>> pip
> > install
> pyignite-0.6.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl
> >
> > You can build and install package from source using this command:
> >>> pip install pyignite-0.6.0.zip
> > You can build wheel on your platform using this command:
> >>> pip wheel --no-deps pyignite-0.6.0.zip
> > For building C module, you should have python headers and C compiler
> > installed.
> > (i.e. for ubuntu sudo apt install build-essential python3-dev)
> > In Mac OS X xcode-tools and python from homebrew are the best option.
> >
> > In order to check whether C module works, use following:
> >>> from pyignite import _cutils
> >>> print(_cutils.hashcode('test'))
> >>> 3556498
> > You can find documentation here:
> >
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc0/
> >
> > You can find examples here (to check them, you should start ignite
> locally):
> >
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc0/examples.html
> > Also, examples can be found in source archive in examples subfolder.
> > docker-compose.yml is supplied in order to start ignite quickly. (Use
> > `docker-compose up -d` to start 3 nodes cluster and `docker-compose
> > down` to shut down it)
> >
> > Release notes:
> >
> https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=a0600047e7b29fc23350f77d4b087cfb55032d72
> >
> > Git release tag was created:
> >
> https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=commit;h=a0600047e7b29fc23350f77d4b087cfb55032d72
> >
> > The vote is formal, see voting guidelines
> > https://www.apache.org/foundation/voting.html
> >
> > +1 - to accept pyignite-0.6.0.rc0
> > 0 - don't care either way
> > -1 - DO NOT accept pyignite-0.6.0.rc0
> >
> > The vote finishes at 11/15/2022 15:00 UTC
> >
>

Re: (UNSUBSCRIBE) [ANNOUNCE] Welcome Mikhail Petrov as a new Committer

[Ivan Daschinsky]

Please, send a mail to dev-unsubscr...@ignite.apache.org

пн, 14 нояб. 2022 г. в 11:58, John Liston :

> UNSUBSCRIBE
>
>
> 
> From: Mikhail Petrov 
> Sent: Monday, November 14, 2022 3:35 AM
> To: dev@ignite.apache.org
> Subject: Re: [ANNOUNCE] Welcome Mikhail Petrov as a new Committer
>
> Thank you all. I appreciate it.
>
> On 11.11.2022 12:48, Anton Vinogradov wrote:
> > Great news!
> > Welcome aboard
> >
> > On Fri, Nov 11, 2022 at 12:03 PM Nikita Amelchev 
> > wrote:
> >
> >> My congratulations, Mikhail!
> >>
> >> пт, 11 нояб. 2022 г. в 11:55, Maksim Timonin :
> >>> Hi Mikhail! Congratulations!
> >>>
> >>> On Fri, Nov 11, 2022 at 11:30 AM Vladimir Steshin 
> >>> wrote:
> >>>
>  Mikhail, congratulations!
> 
>  11.11.2022 11:20, Maxim Muzafarov пишет:
> > The Project Management Committee (PMC) for Apache Ignite has invited
> > Mikhail Petrov to become a committer and we are pleased to announce
> > that they have accepted.
> >
> > Mikhail Petrov is an active contributor and community member, he made
> > significant additions to Ignite and Ignite Extensions code bases,
> >> this
> > client support for Spring Data, Spring Transactions, tracing of SQL
> > queries etc.
> >
> > Being a committer enables easier contribution to the project since
> > there is no need to go via the patch submission process. This should
> > enable better productivity.
> >
> > Please join in welcoming Mikhail Petrov, and congratulating him on
> >> the
> > new role in the Apache Ignite Community!
> >
> >
> > Best Regards,
> > Maxim Muzafarov
> > on behalf of Apache Ignite PMC
> >>
> >>
> >> --
> >> Best wishes,
> >> Amelchev Nikita
> >>
>

[VOTE] Release pyignite 0.6.0.rc0

[Ivan Daschinsky]

Dear Igniters!

Release candidate binaries for subj are uploaded and ready for vote
You can find them here:
https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.6.0.rc0

If you follow the link above, you will find source packages (*.zip)
and binary packages (wheels) for windows (amd64), mac os x (amd64) and
linux (x86_64)
for pythons 37, 38, 39, 310 and 311. Also, there are sha512 and gpg
signatures.
Code signing keys can be found here --
https://downloads.apache.org/ignite/KEYS
Here you can find instructions how to verify packages
https://www.apache.org/info/verification.html

You can install binary package for specific version of python using pip
For example do this on linux for python 3.8
>> pip
install 
pyignite-0.6.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl

You can build and install package from source using this command:
>> pip install pyignite-0.6.0.zip
You can build wheel on your platform using this command:
>> pip wheel --no-deps pyignite-0.6.0.zip

For building C module, you should have python headers and C compiler
installed.
(i.e. for ubuntu sudo apt install build-essential python3-dev)
In Mac OS X xcode-tools and python from homebrew are the best option.

In order to check whether C module works, use following:
>> from pyignite import _cutils
>> print(_cutils.hashcode('test'))
>> 3556498

You can find documentation here:
https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc0/

You can find examples here (to check them, you should start ignite locally):
https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc0/examples.html
Also, examples can be found in source archive in examples subfolder.
docker-compose.yml is supplied in order to start ignite quickly. (Use
`docker-compose up -d` to start 3 nodes cluster and `docker-compose
down` to shut down it)

Release notes:
https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=a0600047e7b29fc23350f77d4b087cfb55032d72

Git release tag was created:
https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=commit;h=a0600047e7b29fc23350f77d4b087cfb55032d72

The vote is formal, see voting guidelines
https://www.apache.org/foundation/voting.html

+1 - to accept pyignite-0.6.0.rc0
0 - don't care either way
-1 - DO NOT accept pyignite-0.6.0.rc0

The vote finishes at 11/15/2022 15:00 UTC

Re: [ANNOUNCE] Release pyignite-0.6.0

[Ivan Daschinsky]

Actually, I've arleady created release branch, release notes. I suppose
that tomorrow I will start a voting process. Is there any objection?

вт, 8 нояб. 2022 г. в 11:18, Igor Sapego :

> +1
>
> Github Actions look great to me.
>
> Best Regards,
> Igor
>
>
> On Mon, Nov 7, 2022 at 5:38 PM Ivan Daschinsky 
> wrote:
>
> > Hi, Igniters!
> >
> > I suppose it is time to release pyignite 0.6.0, since we have released
> our
> > previous release more than a year ago.
> >
> > Firstly, python 3.6 reached its EOL, the brand new python, 3.11, was just
> > released. So it is a good idea to build new wheels targeting the new
> > versions.
> >
> > Also, there are few new features, namely support of timeouts in asyncio
> > client for cache operations. This patch also fixes one tiny but annoying
> > bug in asyncio client [1]
> >
> > Full list of tickets for release is here [2]
> >
> > Actually, I have tested a new approach for testing and building artifacts
> > -- Github Actions, nowadays it is a preferred approach in the ASF.
> >
> > I think that code freeze will be at 15:00 UTC 11/11. And on monday,
> 11/14 I
> > will publish a release candidate for voting.
> >
> > WDYT?
> >
> > [1] -- https://issues.apache.org/jira/browse/IGNITE-18006
> > [2] --
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20python-0.6.0
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

[ANNOUNCE] Release pyignite-0.6.0

[Ivan Daschinsky]

Hi, Igniters!

I suppose it is time to release pyignite 0.6.0, since we have released our
previous release more than a year ago.

Firstly, python 3.6 reached its EOL, the brand new python, 3.11, was just
released. So it is a good idea to build new wheels targeting the new
versions.

Also, there are few new features, namely support of timeouts in asyncio
client for cache operations. This patch also fixes one tiny but annoying
bug in asyncio client [1]

Full list of tickets for release is here [2]

Actually, I have tested a new approach for testing and building artifacts
-- Github Actions, nowadays it is a preferred approach in the ASF.

I think that code freeze will be at 15:00 UTC 11/11. And on monday, 11/14 I
will publish a release candidate for voting.

WDYT?

[1] -- https://issues.apache.org/jira/browse/IGNITE-18006
[2] --
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20python-0.6.0

Re: Ignite OpenSSL Vulnerability

[Ivan Daschinsky]

So you should just download the latest openssl binaries, add them to PATH
and that's it. The ignite odbc driver will load them automatically.
You could also set OPENSSL_HOME env variable to the specific folder with
the valid openssl binaries.

Re: Ignite OpenSSL Vulnerability

[Ivan Daschinsky]

Hi, we don't link our odbc driver with openssl libraries. We load them
dynamically. So don't worry, our odbc driver is not affected at all.
Moreover, it supports multiple versions of openssl, up to 3.0.x

пн, 7 нояб. 2022 г. в 12:17, Ilya Kasnacheev :

> Hello!
>
> For the most part, we to not supply compiled versions of our C++ code, and
> our Java code does not use OpenSSL.
>
> So you should check if you can build ODBC driver against non-affected
> OpenSSL version.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 3 нояб. 2022 г. в 15:45, Entwicklung <
> entwickl...@giftinfo.uni-mainz.de
> >:
>
> > Hello,
> >
> > i hope i use the correct email address.
> >
> > (u...@ignite.apache.org returned wrong
> > email address.)
> >
> >
> >
> > I plan to install Apache Ignite version 2.14.0 binary release (latest) on
> > a windows server. I prefer ODBC-Connection to my application.
> >
> >
> >
> > Problem:
> >
> > ODBC uses OpenSSL, but Version 3.0.0 to 3.0.6 has critical vulnerability.
> > Version 3.0.7 has fixed the problems. Is 2.14.0 binary release
> (especially
> > ODBC) affected ? If yes, when is a new binary release available with
> > OpenSSL 3.0.7.
> >
> > I could not find any information about  the OpenSSL version that Ignite
> > binaries were built from, especially ODBC.
> >
> >
> >
> > Thank you for your help
> > Regards
> > Guido Clesius
> > __
> > Dipl.-Ing. Guido Clesius
> > Externer Mitarbeiter
> > Softwareentwicklung Guido Clesius
> > Im Sand 1
> > 55252 Mainz-Kastel
> > *   06134-9589649
> > Ë 0170-4430211
> > *   supp...@swe-clesius.de
> > þwww.swe-clesius.de
> >
> >
> >
> >
> >
> >
> >
> >
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [ANNOUNCE] Welcome Kirill Tkalenko as a new committer

[Ivan Daschinsky]

Congrats, Kirill!

вт, 11 окт. 2022 г. в 11:26, Denis C :

> Congratulations!
>
> вт, 11 окт. 2022 г. в 09:46, Aleksandr Pakhomov :
>
> > Congratulations!
> >
> > > On 10 Oct 2022, at 22:15, Pavel Tupitsyn  wrote:
> > >
> > > The Project Management Committee (PMC) for Apache Ignite
> > > has invited Kirill Tkalenko to become a committer and we are pleased
> > > to announce that they have accepted.
> > >
> > > Kirill is an active contributor and community member, he made
> significant
> > > additions to Ignite 2.x and 3.x code bases, WAL and PageMemory
> > improvements
> > > among others.
> > >
> > > Being a committer enables easier contribution to the
> > > project since there is no need to go via the patch
> > > submission process. This should enable better productivity.
> > >
> > > Please join me in welcoming Kirill, and congratulating him on the new
> > role
> > > in
> > > the Apache Ignite Community!
> > >
> > > Regards,
> > > Pavel Tupitsyn
> >
> >
>

Re: [VOTE] Release Apache Ignite 2.14.0 RC0

[Ivan Daschinsky]

+1 (binding)

Checked C++ module and C++ examples compilation on windows 10 (msvc 2017)
and ubuntu 22.04 (gcc 11.2.0).
Checked ODBC on windows 10 and ubuntu 22.04 (unixodbc) by pyodbc and python
script (both H2 and CALCITE query engines).
Checked ODBC pre-built binaries on windows 10

Despite the fact that separation of H2 and CALCITE has been announced, H2
(ignite-indexing) is still required for ODBC and CALCITE queries.
Created issue for it -- https://issues.apache.org/jira/browse/IGNITE-17800


пн, 3 окт. 2022 г. в 13:42, mwiesenberg :

> +1
> started a node with calcite, inserted data, ran a sql query.
>
> On Mon, Oct 3, 2022 at 2:46 AM Pavel Tupitsyn 
> wrote:
>
> > +1
> >
> > Started .NET and Java nodes, checked examples, checked NuGet packages.
> >
> > On Fri, Sep 30, 2022 at 4:07 PM Alex Plehanov 
> > wrote:
> >
> > > > Added new experimental, Apache Calcite based SQL engine
> > > It was added in 2.13, in 2.14 it became ignite-indexing (and H2)
> > > independent.
> > >
> > > +1
> > >
> > > Build from sources, start a cluster of two nodes, try some queries on
> > > Calcite SQL engine (with removed ignite-indexing module).
> > >
> > > пт, 30 сент. 2022 г. в 15:02, Zhenya Stanilovsky
> > >  > > >:
> > >
> > > >
> > > >
> > > > I think it`s important to mention that local caches are not supported
> > > > since this version [1].
> > > >
> > > > [1]  https://issues.apache.org/jira/browse/IGNITE-15759
> > > >
> > > >
> > > > >Dear Community,
> > > > >
> > > > >The release candidate is ready.
> > > > >
> > > > >I have uploaded release candidate to
> > > > >https://dist.apache.org/repos/dist/dev/ignite/2.14.0-rc0/
> > > > >https://dist.apache.org/repos/dist/dev/ignite/packages_2.14.0-rc0/
> > > > >
> > > > >The following staging can be used for testing:
> > > > >
> > >
> https://repository.apache.org/content/repositories/orgapacheignite-1552/
> > > > >
> > > > >Tag name is 2.14.0-rc0:
> > > > >
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.14.0-rc0
> > > > >
> > > > >2.14.0 most important changes:
> > > > >* Added new experimental, Apache Calcite based SQL engine
> > > > >* Added support of IGNITE_TO_STRING_INCLUDE_SENSITIVE option by
> > > > Сonsistency check command
> > > > >* CPP Thin: Implemented asynchronous network events handling
> > > > >* CPP thin: Implemented continuous queries
> > > > >* Deprecated IgniteServices#service(String) and
> > > > IgniteServices#services(String).
> > > > >* Implemented CDC for in-memory caches
> > > > >* Implemented NUMA aware allocator for Ignite durable memory
> > > > >* Implemented Read Repair strategies
> > > > >* Implemented array component type in binary object
> > > > >* Removed the legacy service grid implementation
> > > > >
> > > > >RELEASE NOTES:
> > > > >
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.14
> > > > >
> > > > >Complete list of resolved issues:
> > > > >https://issues.apache.org/jira/issues/?jql=(project%20%3D%20
> > > >
> > >
> >
> 'Ignite'%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20('2.14'))%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20and%20status%20in%20('CLOSED'%2C%20'RESOLVED')%20AND%20resolution%20in(Fixed%2C%20Done%2C%20Implemented%2C%20Delivered)%20ORDER%20BY%20priority
> > > > >
> > > > >DEVNOTES
> > > > >
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.14
> > > > >
> > > > >The vote is formal, see voting guidelines
> > > > https://www.apache.org/foundation/voting.html
> > > > >
> > > > >+1 - to accept Apache Ignite 2.14.0-rc0
> > > > >0 - don't care either way
> > > > >-1 - DO NOT accept Apache Ignite Ignite 2.14.0-rc0 (explain why)
> > > > >
> > > > >See notes on how to verify release here
> > > > https://www.apache.org/info/verification.html
> > > > >and
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> > > > >
> > > > >This vote will be open for at least 3 days till Mon Oct 3, 2022,
> 20:00
> > > > UTC.
> > > > >
> > > >
> > >
> >
> https://www.timeanddate.com/countdown/vote?iso=20221003T20=0=VOTE+on+the+Apache+Ignite+Release+2.14.0+RC0=sanserif
> > > > >
> > > > >--
> > > > >With best regards,
> > > > >Taras Ledkov
> > > >
> > > >
> > > >
> > > >
> > >
> >
>

Re: [ANNOUNCE] New PMC member: Ivan Daschinsky

[Ivan Daschinsky]

Thanks a lot, guys, for your congratulations! I really appreciate it.

пн, 19 сент. 2022 г. в 12:19, Nikita Amelchev :

> My congratulations, Ivan!
>
> пн, 19 сент. 2022 г. в 11:28, Maksim Timonin :
> >
> > Hi, Ivan!
> >
> > Congratulations!
> >
> > On Mon, Sep 19, 2022 at 10:05 AM Вячеслав Коптилин <
> slava.kopti...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Congratulations Ivan! Well-deserved!
> > >
> > > Thanks,
> > > Slava.
> > >
> > >
> > > вс, 18 сент. 2022 г. в 12:10, Zhenya Stanilovsky
> > >  > > >:
> > >
> > > >
> > > > Join the congratulations !
> > > >
> > > >
> > > >
> > > >
> > > > >Hi Igniters!
> > > > >
> > > > >The Project Management Committee (PMC) for Apache Ignite has invited
> > > > >Ivan Daschinsky to become a member of the PMC and we are pleased to
> > > > >announce that he has accepted.
> > > > >
> > > > >Ivan contributed the Ignite Python thin client. And he is still
> > > > maintaining
> > > > >it.
> > > > >He is also actively supporting users.
> > > > >
> > > > >Please join me in congratulating Ivan on his new role.
> > > > >
> > > > >Best Regards,
> > > > >Dmitriy Pavlov
> > > > >on behalf of Apache Ignite PMC
> > > >
> > > >
> > > >
> > > >
> > >
>
>
>
> --
> Best wishes,
> Amelchev Nikita
>

Re: Apache calcite dependency update issue.

[Ivan Daschinsky]

Oh, sorry, I see that it has been alredy reported. So let us wait for a bug
fix.

ср, 31 авг. 2022 г., 08:10 Ivan Daschinsky :

> I suppose that we are not in rush, because we have just cut off a release
> branch for 2.14. Let us wait for a new release of Calcite. By the way, has
> that bug been already reported?
>
> вт, 30 авг. 2022 г., 20:35 Zhenya Stanilovsky  >:
>
>>
>> Igniters, i found that new release of apache calcite was released (1.31)
>> [1]. This release contains great improvement [2] which makes possible to
>> resolve [3],  but also contains a bug [4] with natural join validation
>> (possibly not one, but apache ignite sql test suite highlight only this
>> one). I tried to override such a validation in IgniteSqlValidator but seems
>> there are lot of custom private stuff, so i failed here.
>> I don`t have my own opinion here, so we can:
>> *  update calcite version, mute test under calcite issue and wait new
>> calcite release.
>> *  do nothing and just wait new calcite version.
>> What do you think ?
>> Thanks !
>>
>> [1]  https://calcite.apache.org/docs/history.html#v1-31-0
>> [2]  https://issues.apache.org/jira/browse/CALCITE-4913
>> [3]  https://issues.apache.org/jira/browse/IGNITE-16040
>> [4]  https://issues.apache.org/jira/browse/CALCITE-5253
>>
>>
>>
>
>

Re: Apache calcite dependency update issue.

[Ivan Daschinsky]

I suppose that we are not in rush, because we have just cut off a release
branch for 2.14. Let us wait for a new release of Calcite. By the way, has
that bug been already reported?

вт, 30 авг. 2022 г., 20:35 Zhenya Stanilovsky :

>
> Igniters, i found that new release of apache calcite was released (1.31)
> [1]. This release contains great improvement [2] which makes possible to
> resolve [3],  but also contains a bug [4] with natural join validation
> (possibly not one, but apache ignite sql test suite highlight only this
> one). I tried to override such a validation in IgniteSqlValidator but seems
> there are lot of custom private stuff, so i failed here.
> I don`t have my own opinion here, so we can:
> *  update calcite version, mute test under calcite issue and wait new
> calcite release.
> *  do nothing and just wait new calcite version.
> What do you think ?
> Thanks !
>
> [1]  https://calcite.apache.org/docs/history.html#v1-31-0
> [2]  https://issues.apache.org/jira/browse/CALCITE-4913
> [3]  https://issues.apache.org/jira/browse/IGNITE-16040
> [4]  https://issues.apache.org/jira/browse/CALCITE-5253
>
>
>

Re: [ANNOUNCE] New PMC member: Taras Ledkov

[Ivan Daschinsky]

Congrats! Keep on going!

пн, 22 авг. 2022 г., 13:34 Вячеслав Коптилин :

> Congratulations, Taras, very well deserved!
>
> Thanks,
> S.
>
> вс, 21 авг. 2022 г. в 19:26, Ilya Shishkov :
>
> > Congratulations, Taras!
> >
> > вс, 21 авг. 2022 г. в 09:52, Pavel Tupitsyn :
> >
> > > Congrats!
> > >
> > > Pavel
> > >
> > > On Sun, Aug 21, 2022 at 9:07 AM Ivan Pavlukhin 
> > > wrote:
> > >
> > > > Congratulations, Taras!
> > > >
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > > > сб, 20 авг. 2022 г. в 00:18, Dmitriy Pavlov :
> > > > >
> > > > > Hi Igniters!
> > > > >
> > > > > The Project Management Committee (PMC) for Apache Ignite has
> invited
> > > > > Taras Ledkov to become a member of the PMC and we are pleased to
> > > > > announce that he has accepted.
> > > > >
> > > > > Taras is a veteran committer, and it is needless to say how long
> > > > > and successfully he is contributing to the Apache Ignite.
> > > > > Taras is responsible for a solid bulk of SQL and JDBC code.
> > > > >
> > > > > Please join me in congratulating Taras on his new role.
> > > > >
> > > > > Best Regards,
> > > > > Dmitriy Pavlov
> > > > > on behalf of Apache Ignite PMC
> > > >
> > >
> >
>

Re: [ANNOUNCE] New PMC member: Vyacheslav Koptilin

[Ivan Daschinsky]

Congrats, Slava!

чт, 18 авг. 2022 г. в 18:26, Вячеслав Коптилин :

> Hi Igniters,
>
> Many thanks to all of you! I really appreciate this.
>
> Thanks,
> S.
>
> чт, 18 авг. 2022 г. в 17:17, Andrey Mashenkov  >:
>
> > Congratulations, Slava!
> >
> > On Wed, Aug 17, 2022 at 5:35 PM Kseniya Romanova 
> > wrote:
> >
> > > Hi Igniters!
> > >
> > > The Project Management Committee (PMC) for Apache Ignite has invited
> > > Vyacheslav Koptilin to become a member of the PMC and we are pleased to
> > > announce that he has accepted.
> > >
> > > Vyacheslav is a veteran committer and contributes a lot to the Ignite
> > > storage https://github.com/sk0x50.
> > >
> > > Please join me in congratulating Vyacheslav on his new role.
> > >
> > > Best Regards,
> > > Kseniya Romanova
> > > on behalf of Apache Ignite PMC
> > >
> >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients

[Ivan Daschinsky]

I am strongly against serialization, it simply doesn't work except some
trivial cases. Explicit is better than implicit.

вт, 12 июл. 2022 г., 12:56 Ivan Daschinsky :

> Unfortunately, affinity function is not rivially constructible, at least
> default one
>
> вт, 12 июл. 2022 г., 10:37 Pavel Tupitsyn :
>
>> Alex, the second option is exactly what I've proposed above.
>>
>> On Tue, Jul 12, 2022 at 9:46 AM Alex Plehanov 
>> wrote:
>>
>> > Folks, why should we construct a fully functional affinity function on
>> the
>> > client side by custom client code? We need only a key to partition
>> mapping,
>> > so only this simple mapper factory will be enough.
>> > From my point of view there are to options possible:
>> > - provide ability to set partition to key mapper factory by the client
>> code
>> > or
>> > - serialize custom affinity functions and custom affinity key mappers to
>> > binary objects and send it together with ClientCachePartitionResponse
>> > message. In this case, explicit client configuration or some kind of
>> client
>> > code is not required, affinity function (with type id and its internals)
>> > will be deserialized if classes are present on thin-client side and
>> will be
>> > used implicitly (for java thin client). For other thin clients (except
>> > java) type id can be retrieved from the binary object and some key to
>> > partition mapper can be provided based on this type id (for example by
>> > configured factory).
>> >
>> > пн, 11 июл. 2022 г. в 16:22, Pavel Tupitsyn :
>> >
>> > > No objections to the AffinityFunctionFactory approach from my side.
>> > > I think it should be based on cacheName, not groupId.
>> > >
>> > > On Mon, Jul 11, 2022 at 3:52 PM Maxim Muzafarov 
>> > wrote:
>> > >
>> > > > Folks,
>> > > >
>> > > > I've done research about the proposed solution and I'd like to
>> discuss
>> > > > with you a possible options we may have. After we agreed on a
>> solution
>> > > > design I'll create a new IEP with everything we've discussed above.
>> > > >
>> > > > So, let's consider the most completed case:
>> > > > the RendezvousAffinityFunction with a custom affinity mapper
>> function
>> > is
>> > > > used.
>> > > >
>> > > >
>> > > > =
>> > > >
>> > > > The  solution with sending AffintyFunction typeId.
>> > > >
>> > > > a. The deprecated AffinityKeyMapper used prior to the
>> AffinityFunction
>> > > > for calculation a key to partition mapping.
>> > > > See the link [1] - affFunction.partition(affinityKey(key))
>> > > >
>> > > > b. We are able to map typeId of the RendezvousAffinityFunction to
>> > > > another AffinityFunction on the client side to solve the mapping
>> > > > problem with any combination of AffinityFunction and
>> > > > AffinityKeyMappers ware used.
>> > > >
>> > > > c. When the cache partitions mapping request [2] is executed we are
>> > > > able to send the typeId of the RendezvousAffinityFunction back to
>> the
>> > > > client, however without sending the typeId's of custom affinity
>> > > > mappers we are not able to identify the case when a substitution of
>> > > > the AffinityFunction is required on the client side.
>> > > >
>> > > > For instance,
>> > > >
>> > > > cacheGroup_1 has RendezvousAffinityFunction + FirstAffinityKeyMapper
>> > > > cacheGroup_2 has RendezvousAffinityFunction +
>> SecondAffinityKeyMapper
>> > > >
>> > > > Adding a deprecated classes and their corresponding typeId's to the
>> > > > exchange client-server protocol sound not a good idea. However, this
>> > > > will cover all the cases.
>> > > >
>> > > > =
>> > > >
>> > > > The  solution with factory method for AffintyFunction on the client
>> > side.
>> > > >
>> > > > We can also improve the solution that was proposed by me a few
>> > > > messages ago. Instead of the withPartitionAwarenessKeyMapper() [4]
>> > > > method which looks a bit weird we can add a factory method to the
>> > > > 

Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients

[Ivan Daschinsky]

}
> > > > }
> > > >
> > > > This cases will have a bit straightforward implementation and
> explicit
> > > > AffinityFunction initialization by a user.
> > > >
> > > >
> > > > WDYT?
> > > >
> > > >
> > > >
> > > > [1]
> > > >
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheAffinityManager.java#L185
> > > > [2]
> > > >
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/platform/client/ClientMessageParser.java#L535
> > > > [3]
> > > >
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/cache/affinity/AffinityFunction.java#L53
> > > > [4]
> > > >
> > >
> >
> https://github.com/apache/ignite/pull/10140/files#diff-fb60155466fa2c31d6d1270c0e08f15f1ad9c1a2272fc9bb137c07d9ae5c1b98R47
> > > >
> > > > On Mon, 11 Jul 2022 at 13:14, Ivan Daschinsky 
> > > wrote:
> > > > >
> > > > > Still don't understand how type id can help me to obtain valid
> mapper
> > > > from
> > > > > key to int32. Especially when we are talking about non-jvm
> languages.
> > > > >
> > > > > пн, 11 июл. 2022 г., 12:33 Николай Ижиков :
> > > > >
> > > > > > Pavel.
> > > > > >
> > > > > > > It is not cryptic, it is very straightforward and builds on
> > > existing
> > > > > > binary type mechanism.
> > > > > >
> > > > > > I see the Ivan’s point here.
> > > > > > As I said earlier - It must be absolutely clear for user - PA
> works
> > > or
> > > > not.
> > > > > >
> > > > > > With the logic you propose it will be hiding inside Ignite
> > machinery
> > > > and
> > > > > > logs.
> > > > > >
> > > > > > > Unfortunately, this is a breaking change. Currently this
> scenario
> > > > works
> > > > > > without errors - uses default socket for custom affinity caches.
> > > > > >
> > > > > > It’s OK from my point of view to introduce such a change.
> > > > > >
> > > > > >
> > > > > > > 10 июля 2022 г., в 22:05, Pavel Tupitsyn  >
> > > > > > написал(а):
> > > > > > >
> > > > > > >> providing simple function Object -> int32 in cache
> configuration
> > > is
> > > > > > wrong
> > > > > > > decision
> > > > > > >
> > > > > > > Because it is error-prone and does not work for all cases:
> > > > > > > - You have to set it explicitly on the client for every cache.
> > > > > > > - No way to do that if you get an existing cache by name.
> > > > > > >
> > > > > > >> still being unable to solve the problem
> > > > > > >
> > > > > > > I believe the proposed solution covers all use cases.
> > > > > > >
> > > > > > >> cryptic logic
> > > > > > >
> > > > > > > It is not cryptic, it is very straightforward and builds on
> > > existing
> > > > > > binary
> > > > > > > type mechanism.
> > > > > > >
> > > > > > >> feature flags
> > > > > > >
> > > > > > > What's bad about feature flags?
> > > > > > >
> > > > > > >> how an ability to obtain a classname of java class can help my
> > > > python or
> > > > > > > C++ client map key to partition
> > > > > > >
> > > > > > > Not a java class name, but type id. You can set up type id
> > mapping
> > > > > > properly
> > > > > > > and use this in any thin client.
> > > > > > > This will work for .NET client, not sure about Python and C++.
> > > > > > >
> > > > > > > On Sun, Jul 10, 2022 at 9:33 PM Ivan Daschinsky <
> > > ivanda...@gmail.com
> > > > &

Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients

[Ivan Daschinsky]

Still don't understand how type id can help me to obtain valid mapper from
key to int32. Especially when we are talking about non-jvm languages.

пн, 11 июл. 2022 г., 12:33 Николай Ижиков :

> Pavel.
>
> > It is not cryptic, it is very straightforward and builds on existing
> binary type mechanism.
>
> I see the Ivan’s point here.
> As I said earlier - It must be absolutely clear for user - PA works or not.
>
> With the logic you propose it will be hiding inside Ignite machinery and
> logs.
>
> > Unfortunately, this is a breaking change. Currently this scenario works
> without errors - uses default socket for custom affinity caches.
>
> It’s OK from my point of view to introduce such a change.
>
>
> > 10 июля 2022 г., в 22:05, Pavel Tupitsyn 
> написал(а):
> >
> >> providing simple function Object -> int32 in cache configuration is
> wrong
> > decision
> >
> > Because it is error-prone and does not work for all cases:
> > - You have to set it explicitly on the client for every cache.
> > - No way to do that if you get an existing cache by name.
> >
> >> still being unable to solve the problem
> >
> > I believe the proposed solution covers all use cases.
> >
> >> cryptic logic
> >
> > It is not cryptic, it is very straightforward and builds on existing
> binary
> > type mechanism.
> >
> >> feature flags
> >
> > What's bad about feature flags?
> >
> >> how an ability to obtain a classname of java class can help my python or
> > C++ client map key to partition
> >
> > Not a java class name, but type id. You can set up type id mapping
> properly
> > and use this in any thin client.
> > This will work for .NET client, not sure about Python and C++.
> >
> > On Sun, Jul 10, 2022 at 9:33 PM Ivan Daschinsky 
> wrote:
> >
> >> Guys, I simply cant understand why providing simple function Object ->
> >> int32 in cache configuration is wrong decision, but implementing cryptic
> >> logic with class names, feature flags and still being unable to solve
> the
> >> probem is ok. I don't understand how an ability to obtain a classname of
> >> java class can help my python or C++ client map key to partition.
> >>
> >> Max's proposal seems to be a good variant, just change naming a little
> bit,
> >> maybe
> >>
> >> пт, 8 июл. 2022 г., 15:35 Pavel Tupitsyn :
> >>
> >>> Nikolay,
> >>>
> >>>> Add ability to sent custom affinity class name.
> >>> Can you please elaborate? What is sent where?
> >>>
> >>>> If `partitionAwarenessEnabled=true` but custom affinity can’t be
> >>> instantiated on the client - throw an exception
> >>> Unfortunately, this is a breaking change. Currently this scenario works
> >>> without errors - uses default socket for custom affinity caches.
> >>>
> >>>
> >>> On Fri, Jul 8, 2022 at 3:23 PM Николай Ижиков 
> >> wrote:
> >>>
> >>>> Hello, Pavel.
> >>>>
> >>>> I support your proposal to transparently create custom AffinityMapper
> >>>> based on server node classname, in general.
> >>>> Partition Awareness crucial point for a thin client performance so It
> >>>> should be absolutely clear for a user - PA works correctly or not.
> >>>>
> >>>> So, I think, we should implement the following:
> >>>>
> >>>> 0. Add ability to sent custom affinity class name.
> >>>> 1. If `partitionAwarenessEnabled=true` but custom affinity can’t be
> >>>> instantiated on the client - throw an exception.
> >>>>
> >>>> WDYT?
> >>>>
> >>>>> 8 июля 2022 г., в 08:37, Pavel Tupitsyn 
> >>>> написал(а):
> >>>>>
> >>>>> To clarify: you can use a different AffinityFunction implementation
> >> on
> >>>> the
> >>>>> client side. It just has to map to the same binary typeId.
> >>>>> Even if there is a legacy setup with AffinityKeyMapper on servers,
> >> you
> >>>> can
> >>>>> craft an AffinityFunction for the client that achieves correct
> >>> behavior.
> >>>>> So I believe this should cover any use case.
> >>>>>
> >>>>> On Thu, Jul 7, 2022 at 10:36 PM Pavel Tupitsyn  >>>
> >>>> wrote:
> >>>

Re: [DISCUSSION] Customers Migraton from Thick to Thin Clients

[Ivan Daschinsky]

Guys, I simply cant understand why providing simple function Object ->
int32 in cache configuration is wrong decision, but implementing cryptic
logic with class names, feature flags and still being unable to solve the
probem is ok. I don't understand how an ability to obtain a classname of
java class can help my python or C++ client map key to partition.

Max's proposal seems to be a good variant, just change naming a little bit,
maybe

пт, 8 июл. 2022 г., 15:35 Pavel Tupitsyn :

> Nikolay,
>
> > Add ability to sent custom affinity class name.
> Can you please elaborate? What is sent where?
>
> > If `partitionAwarenessEnabled=true` but custom affinity can’t be
> instantiated on the client - throw an exception
> Unfortunately, this is a breaking change. Currently this scenario works
> without errors - uses default socket for custom affinity caches.
>
>
> On Fri, Jul 8, 2022 at 3:23 PM Николай Ижиков  wrote:
>
> > Hello, Pavel.
> >
> > I support your proposal to transparently create custom AffinityMapper
> > based on server node classname, in general.
> > Partition Awareness crucial point for a thin client performance so It
> > should be absolutely clear for a user - PA works correctly or not.
> >
> > So, I think, we should implement the following:
> >
> > 0. Add ability to sent custom affinity class name.
> > 1. If `partitionAwarenessEnabled=true` but custom affinity can’t be
> > instantiated on the client - throw an exception.
> >
> > WDYT?
> >
> > > 8 июля 2022 г., в 08:37, Pavel Tupitsyn 
> > написал(а):
> > >
> > > To clarify: you can use a different AffinityFunction implementation on
> > the
> > > client side. It just has to map to the same binary typeId.
> > > Even if there is a legacy setup with AffinityKeyMapper on servers, you
> > can
> > > craft an AffinityFunction for the client that achieves correct
> behavior.
> > > So I believe this should cover any use case.
> > >
> > > On Thu, Jul 7, 2022 at 10:36 PM Pavel Tupitsyn 
> > wrote:
> > >
> > >> AffinityKeyMapper is just a subset of AffinityFunction, isn't it?
> > >> So by supporting AffinityFunction we cover all AffinityKeyMapper use
> > cases.
> > >>
> > >>
> > >>> managing the classpath, a user should always keep in mind it
> > >> I don't consider this a problem. This is how Java works, what can we
> do?
> > >> You can also stick the class into BinaryConfiguration on the client to
> > >> make it explicit and make sure it is loaded.
> > >>
> > >>> it still possible having user bad implementations of AffinityFunction
> > >> that can't be easily instantiated;
> > >> It is also possible to provide a bad implementation of ToIntFunction,
> no
> > >> difference.
> > >>
> > >>> a question - what we should do in case of class instantiating loading
> > >> fails?
> > >> Currently we don't fail on custom affinity, right? So we should keep
> > this
> > >> behavior. Print a warning.
> > >>
> > >> On Thu, Jul 7, 2022 at 10:27 PM Maxim Muzafarov 
> > wrote:
> > >>
> > >>> Pavel,
> > >>>
> > >>>
> > >>> Yes, you're right that AffinityKeyMapper is deprecated, this is sad
> to
> > >>> say but it still used.
> > >>>
> > >>> Let me describe the cases in more detail. In general, we have
> > >>> customers which are using:
> > >>>
> > >>> 1. an own custom AffinityFunction;
> > >>> 2. the default RendezvousAffinityFunction + an own deprecated
> > >>> AffinityKeyMapper;
> > >>> 3. an own custom AffinityFunction + an own deprecated
> > >>> AffinityKeyMapper (I doubt about this case);
> > >>>
> > >>> I'd like to provide a general solution that solves all the cases
> > >>> mentioned above, thus we can't discuss only AffinityFunction. It
> > >>> doesn't fit the initial goals.
> > >>>
> > >>>
> >  Can you please clarify the "tricky" part?
> > >>>
> > >>> Yes, from my point of view the tricky part here is:
> > >>>
> > >>> - managing the classpath, a user should always keep in mind it;
> > >>> - it still possible having user bad implementations of
> > >>> AffinityFunction that can't be easily instantiated;
> > >>> - a question - what we should do in case of class instantiating
> > >>> loading fails? drop the client, print the warn or do nothing. These
> > >>> solutions have a different impact on a production environment and
> user
> > >>> may have different expectations on that;
> > >>>
> > >>>
> > >>> I'm not saying that solution you suggested is bad, it just has some
> > >>> drawbacks (like other solutions) and doesn't solves all the cases if
> > >>> we're not instantiating a deprecated AffinityKeyMapper (which looks a
> > >>> bit ugly for me too).
> > >>>
> > >>>
> > >>> Actually, we are not limited with setting/instantiating
> > >>> AffinityFunction. We can provide for a user a control on which
> channel
> > >>> (node) a particular cache request will be executed (this thing also
> > >>> have a drawback - a transactional operation cannot be executed on an
> > >>> arbitrary node, it should be executed on node it's started).
> > >>>
> > >>> On Thu, 7 Jul 2022 at 21:41, 

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

[Ivan Daschinsky]

Seems that we forgot to disable the cloud test suite after removing this
module?

ср, 15 июн. 2022 г. в 10:53, :

> 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 Cloud
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cloud?branch=%3Cdefault%3E
>  Changes may lead to failure were done by
>  - taras ledkov 
> https://ci2.ignite.apache.org/viewModification.html?modId=956671
>  - nao <56360298+nao...@users.noreply.github.com>
> https://ci2.ignite.apache.org/viewModification.html?modId=956668
>  - maxim muzafarov 
> https://ci2.ignite.apache.org/viewModification.html?modId=956715
>  - slava koptilin 
> https://ci2.ignite.apache.org/viewModification.html?modId=956760
>  - korlov42 
> https://ci2.ignite.apache.org/viewModification.html?modId=956693
>  - igor sapego 
> https://ci2.ignite.apache.org/viewModification.html?modId=956629
>  - roman puchkovskiy 
> https://ci2.ignite.apache.org/viewModification.html?modId=956690
>  - nikolay 
> https://ci2.ignite.apache.org/viewModification.html?modId=956739
>  - andrew v. mashenkov 
> https://ci2.ignite.apache.org/viewModification.html?modId=956675
>  - aleksey plekhanov 
> https://ci2.ignite.apache.org/viewModification.html?modId=956705
>
>  - 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 07:53:21 15-06-2022
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: .NET Build and Versioning Improvements

[Ivan Daschinsky]

As for the last number in .NET version, AFAIK it is used as the unique
build id and is required for nightly builds as nuget doesn't have
functionality a-la maven's 'snapshots'

ср, 8 июн. 2022 г. в 16:07, Ivan Daschinsky :

> Since nuget packages have been built on the same linux agent as the main
> release, it sounds logical to me that this step can be done within the
> maven lifecycle.
> I am for it, +1
>
> ср, 8 июн. 2022 г. в 15:13, Maxim Muzafarov :
>
>> Hello Igniters,
>>
>>
>> I'd like to simplify the release build for the Apache Ignite.
>>
>> My suggestion here are:
>> 1. Mavenize the building procedure of the 'platform/donet' thin client
>> (use maven with Ant task)
>> 2. Change it's versions to fit the Ignite style.
>>
>>
>> = 1. Build =
>>
>> Add a pom.xml sub-project with a corresponding maven-ant-plugin with a
>> Ant task to build the .NET project when the Apache Ignite project
>> build. We can use here a profile like the numa-allocator does if
>> building the .NET is note required.
>>
>> Such a technique will also allow a variables substitution like the
>> maven-resource-plugin works (e.g. version substitution).
>>
>> Here is an example of how it can be achieved:
>>
>> https://github.com/apache/ignite/pull/9497/files#diff-77baf2378aa83911a8c3091814db3ff60b7bf328c4ab4850f707717ed96f3d92R107
>>
>>
>> = 2. Versioning =
>>
>> Currently, the version of .NET thin client (SharedAssemblyInfo.cs [1])
>> have the following format:
>> 2.14.0.62943 . The format of .NET versions Major.Minor.Patch.Revision
>> (described here [2]).
>>
>> Since the Apache Ignite doesn't have a dedicated releases for the .NET
>> thin client I think the last 'Revision' digits can be always set to
>> zero. So the result version can be:
>> 2.14.0.0
>>
>> This will allow having the variable substitution also for the version
>> number and omitt the update-version profile usage for the .NET client.
>>
>>
>> = Advantages =
>>
>> - Reduce the code complexity for changing a project version (we don't
>> need the update-versions maven profile);
>> - Build the whole project on the local environment and prepare nuget
>> for the release with a single command;
>>
>>
>> [1]
>> https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/SharedAssemblyInfo.cs
>> [2]
>> https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#where-nugetversion-diverges-from-semantic-versioning
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: .NET Build and Versioning Improvements

[Ivan Daschinsky]

Since nuget packages have been built on the same linux agent as the main
release, it sounds logical to me that this step can be done within the
maven lifecycle.
I am for it, +1

ср, 8 июн. 2022 г. в 15:13, Maxim Muzafarov :

> Hello Igniters,
>
>
> I'd like to simplify the release build for the Apache Ignite.
>
> My suggestion here are:
> 1. Mavenize the building procedure of the 'platform/donet' thin client
> (use maven with Ant task)
> 2. Change it's versions to fit the Ignite style.
>
>
> = 1. Build =
>
> Add a pom.xml sub-project with a corresponding maven-ant-plugin with a
> Ant task to build the .NET project when the Apache Ignite project
> build. We can use here a profile like the numa-allocator does if
> building the .NET is note required.
>
> Such a technique will also allow a variables substitution like the
> maven-resource-plugin works (e.g. version substitution).
>
> Here is an example of how it can be achieved:
>
> https://github.com/apache/ignite/pull/9497/files#diff-77baf2378aa83911a8c3091814db3ff60b7bf328c4ab4850f707717ed96f3d92R107
>
>
> = 2. Versioning =
>
> Currently, the version of .NET thin client (SharedAssemblyInfo.cs [1])
> have the following format:
> 2.14.0.62943 . The format of .NET versions Major.Minor.Patch.Revision
> (described here [2]).
>
> Since the Apache Ignite doesn't have a dedicated releases for the .NET
> thin client I think the last 'Revision' digits can be always set to
> zero. So the result version can be:
> 2.14.0.0
>
> This will allow having the variable substitution also for the version
> number and omitt the update-version profile usage for the .NET client.
>
>
> = Advantages =
>
> - Reduce the code complexity for changing a project version (we don't
> need the update-versions maven profile);
> - Build the whole project on the local environment and prepare nuget
> for the release with a single command;
>
>
> [1]
> https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/SharedAssemblyInfo.cs
> [2]
> https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#where-nugetversion-diverges-from-semantic-versioning
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [VOTE] Release Apache Ignite 2.13.0 RC2

[Ivan Daschinsky]

+0.5

Checked ODBC drivers binaries on windows (32 and 64 bit) using pyodbc and
python 3.8
Checked both H2 and Calcite engines (setted in DSN and Connection
configurations)

Works with issues -- cannot start ignite without copying slf4j-api jar into
ignite-calcite module. Calcite depends itself on slf4-api, however it is
not added to the ignite-calcite folder.

I am not sure whether it is a blocker or not. I incline towards not
rejecting the release due to the minority of the issue.

пн, 25 апр. 2022 г. в 22:23, Maxim Muzafarov :

> +1 (binding)
>
> Checked parent project, versions, dependencies.
>
> On Mon, 25 Apr 2022 at 12:06, Ilya Kasnacheev 
> wrote:
> >
> > +1 (binding)
> >
> > Ran a slim node, built from sources, built and ran c++ node.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 25 апр. 2022 г. в 08:55, Николай Ижиков :
> >
> > > +1 (binding)
> > >
> > > > 23 апр. 2022 г., в 17:32, Nikita Amelchev 
> > > написал(а):
> > > >
> > > > Hi Igniters, PMCs,
> > > >
> > > > Please, verify a new release candidate.
> > > >
> > > > The vote will continue until there are enough votes for a
> resolution. [1]
> > > >
> > > > [1] https://www.apache.org/foundation/voting.html#ReleaseVotes
> > > >
> > > > пт, 22 апр. 2022 г. в 08:24, Zhenya Stanilovsky
> > > :
> > > >>
> > > >>
> > > >> Nikita thanks for your effort !
> > > >> Download sources, run examples.
> > > >> +1 from me.
> > > >>
> > > >>> Dear Community,
> > > >>>
> > > >>> The release candidate is ready.
> > > >>>
> > > >>> I have uploaded a release candidate to:
> > > >>> https://dist.apache.org/repos/dist/dev/ignite/2.13.0-rc2/
> > > >>> https://dist.apache.org/repos/dist/dev/ignite/packages_2.13.0-rc2/
> > > >>>
> > > >>> The following staging can be used for testing:
> > > >>>
> > >
> https://repository.apache.org/content/repositories/orgapacheignite-1542
> > > >>>
> > > >>> Tag name is 2.13.0-rc1:
> > > >>>
> > >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=refs/tags/2.13.0-rc2
> > > >>>
> > > >>> RELEASE_NOTES:
> > > >>>
> > >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.13
> > > >>>
> > > >>> Complete list of resolved issues:
> > > >>>
> > >
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.13%27))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20ORDER%20BY%20priority
> > > >>>
> > > >>> DEVNOTES:
> > > >>>
> > >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.13
> > > >>>
> > > >>> Additional checks have been performed (available for users included
> > > >>> into the release group on TeamCity).
> > > >>>
> > > >>> TC [Check RC: Licenses, compile, chksum]
> > > >>>
> > >
> https://ci2.ignite.apache.org/buildConfiguration/ignite2_Release_ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum/6399934
> > > >>>
> > > >>> TC [2] Compare w/ Previous Release
> > > >>>
> > >
> https://ci2.ignite.apache.org/buildConfiguration/ignite2_Release_ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency/6399932
> > > >>>
> > > >>> The vote is formal, see voting guidelines
> > > >>> https://www.apache.org/foundation/voting.html
> > > >>>
> > > >>> +1 - to accept Apache Ignite 2.13.0-rc2
> > > >>> 0 - don't care either way
> > > >>> -1 - DO NOT accept Apache Ignite Ignite 2.13.0-rc2 (explain why)
> > > >>>
> > > >>> See notes on how to verify release here
> > > >>> https://www.apache.org/info/verification.html
> > > >>> and
> > > >>>
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> > > >>>
> > > >>> This vote will be open for at least 3 days till Fri Apr 23, 2022,
> > > >>> 20:00 UTC. Please, write me down the thread if you need additional
> > > >>> time to check the
> > > >>> release.
> > > >>>
> > >
> https://www.timeanddate.com/countdown/vote?iso=20220423T20=0=VOTE+on+the+Apache+Ignite+Release+2.13.0+RC2=sanserif
> > > >>>
> > > >>> --
> > > >>> Best wishes,
> > > >>> Amelchev Nikita
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Best wishes,
> > > > Amelchev Nikita
> > >
> > >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [VOTE] Release Apache Ignite 2.13.0 RC1

[Ivan Daschinsky]

It seems that we only add numa-allocator to profiles list in
intiialize task, i.e.

 mvn initialize -Prelease,numa-allocator,all-scala
-Dignite.edition=apache-ignite-slim

ср, 20 апр. 2022 г. в 14:57, Nikita Amelchev :

> Ivan, please create an issue to add to the assembly. I'll
> cherry-picked and prepare a new RC.
>
> ср, 20 апр. 2022 г. в 14:45, Ivan Daschinsky :
>
> >
> > Seems that somehow numa-allocator is not included in binary releases.
> >
> > ср, 20 апр. 2022 г. в 14:14, Nikita Amelchev :
> >
> > > I will make sure this issue is included in the 2.13 documentation.
> Thanks.
> > >
> > > ср, 20 апр. 2022 г. в 14:09, 18624049226 <18624049...@163.com>:
> > > >
> > > > I think the following commit should be included in 2.13:
> > > >
> > > > IGNITE-15712: Documentation: Invalid documentation about
> > > > SqlViewMetricExporterSpi
> > > >
> > > > just doc issue.
> > > >
> > > > 在 2022/4/20 16:21, Nikita Amelchev 写道:
> > > > > Zhenya, Hi!
> > > > >
> > > > > Additional checks are available for users included into the release
> > > > > group on TeamCity. Make sure you are in this group.
> > > > >
> > > > > ср, 20 апр. 2022 г. в 09:19, Zhenya
> > > Stanilovsky:
> > > > >>
> > > > >> Nikita, thanks !  I found that below link is unavailable:
> > > > >>
> > > > >>
> > > > >>
> > > > >>> TC [2] Compare w/ Previous Release
> > > > >>>
> > >
> https://ci2.ignite.apache.org/buildConfiguration/ignite2_Release_ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency/6398741
> > > > >>>
> > > > >>
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Best wishes,
> > > Amelchev Nikita
> > >
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
>
>
>
> --
> Best wishes,
> Amelchev Nikita
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [VOTE] Release Apache Ignite 2.13.0 RC1

[Ivan Daschinsky]

Seems that somehow numa-allocator is not included in binary releases.

ср, 20 апр. 2022 г. в 14:14, Nikita Amelchev :

> I will make sure this issue is included in the 2.13 documentation. Thanks.
>
> ср, 20 апр. 2022 г. в 14:09, 18624049226 <18624049...@163.com>:
> >
> > I think the following commit should be included in 2.13:
> >
> > IGNITE-15712: Documentation: Invalid documentation about
> > SqlViewMetricExporterSpi
> >
> > just doc issue.
> >
> > 在 2022/4/20 16:21, Nikita Amelchev 写道:
> > > Zhenya, Hi!
> > >
> > > Additional checks are available for users included into the release
> > > group on TeamCity. Make sure you are in this group.
> > >
> > > ср, 20 апр. 2022 г. в 09:19, Zhenya
> Stanilovsky:
> > >>
> > >> Nikita, thanks !  I found that below link is unavailable:
> > >>
> > >>
> > >>
> > >>> TC [2] Compare w/ Previous Release
> > >>>
> https://ci2.ignite.apache.org/buildConfiguration/ignite2_Release_ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency/6398741
> > >>>
> > >>
> > >
> > >
>
>
>
> --
> Best wishes,
> Amelchev Nikita
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: TeamCity #1: Problem with 'ZooKeeper (Discovery) 1'

[Ivan Daschinsky]

Seems that after update of zookeeper and curator, behaviour of testing
cluster have been slightly changed. I've tried to
increase zookeeper.electionPortBindRetry for testing zk ensemble
nodes and seems all issues are resolved now.

пн, 4 апр. 2022 г. в 17:37, Ilya Shishkov :

> Hi all,
>
> As I see TC#1 (ci.ignite.apache.org) experiences problems with 'ZooKeeper
> (Discovery) 1' test suite execution (master branch).
> There are such errors in logs as below [1, 2]:
>   [2022-04-04 03:37:09,971][ERROR][QuorumPeerListener][ServiceUtils]
> Exiting JVM with code 14
>   Process exited with code 14
>
> I checked  TC#2 (ci2.ignite.apache.org) and found out that the amount of
> test runs on TC2 [3, 4] is more than those on TC1 [5, 6]. And, BTW,
> there are no problems with exit code on TC#2.
>
> It seems to be an infrastructure problem, because as I understand,
> Zookeeper can't bind to a port. This line is from Zookeeper ExitCode class
> [7]:
> /** Unable to bind to the quorum (election) port after multiple retry
> */
> UNABLE_TO_BIND_QUORUM_PORT(14);
>
> Please, can anyone take a look at possible misconfiguration on TC#1?
>
> Links:
> 1.
>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ZooKeeperDiscovery1/6500597?showLog=6500597_230432_890.962.230567.230604=debug
> 2.
>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ZooKeeperDiscovery1/6501316?showLog=6501316_228931_890.962.228942=debug
> 4.
>
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ZooKeeperDiscovery1/6376069?buildTab=tests=classes
> 5 .
>
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ZooKeeperDiscovery1/6377319?buildTab=tests=classes
>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ZooKeeperDiscovery1/6500597?buildTab=tests=passed=classes
> 6.
>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ZooKeeperDiscovery1/6501316?buildTab=tests=classes=all
> 7.
>
> https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/ExitCode.java#L51
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Empty test report for 'Control-utility' and 'Zookeeper

[Ivan Daschinsky]

Great job Maxim!

пн, 28 мар. 2022 г. в 15:51, Maksim Timonin :

> Hi, guys!
>
> I investigated the issue. This is due to commit: fe95954c. It updated the
> curator-test version in the control-utility module (from 4.2.0 to 5.2.0).
> It led to changed transitive dependencies (jar-hell) of junit and tests
> just don't start due to different junit version (5 instead of 4).
>
> I'll fix it today.
>
> On Mon, Mar 28, 2022 at 11:50 AM Ivan Daschinsky 
> wrote:
>
> > Problem was introduced in 2b74474b7220df046c5c6d7a12a23ba90a697025. Suite
> > has not been run since that commit.
> >
> > чт, 24 мар. 2022 г. в 19:01, Shishkov Ilya :
> >
> > > Hi everyone,
> > >
> > > As I see, both 'Control Utility' and 'Control Utility (Zookeeper)' test
> > > suites have empty test results and there are messages in a build log as
> > > below:
> > >
> > > Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> > >
> > > Above problem occurs both on TC1 and TC2 [1-4] for the master branch,
> but
> > > does not on the 'ignite-2.12' [5-8].
> > >
> > > Can anyone take a look, please?
> > >
> > > Links:
> > > 1.
> > >
> > >
> >
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility/6480112?showLog=6480112_1061_895
> > > 2.
> > >
> > >
> >
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6480111?showLog=6480111_1060_894
> > > 3.
> > >
> > >
> >
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility/6359892?showRootCauses=true=6359892_1003_909
> > > 4.
> > >
> > >
> >
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6359893?showRootCauses=true=6359893_1003_909
> > > .
> > > 5.
> > >
> > >
> >
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility/6479329
> > > 6.
> > >
> > >
> >
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6479328
> > > 7.
> > >
> > >
> >
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility/6359189?showRootCauses=true=true
> > > 8.
> > >
> > >
> >
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6359190?showRootCauses=true=true
> > >
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Empty test report for 'Control-utility' and 'Zookeeper

[Ivan Daschinsky]

Problem was introduced in 2b74474b7220df046c5c6d7a12a23ba90a697025. Suite
has not been run since that commit.

чт, 24 мар. 2022 г. в 19:01, Shishkov Ilya :

> Hi everyone,
>
> As I see, both 'Control Utility' and 'Control Utility (Zookeeper)' test
> suites have empty test results and there are messages in a build log as
> below:
>
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
>
> Above problem occurs both on TC1 and TC2 [1-4] for the master branch, but
> does not on the 'ignite-2.12' [5-8].
>
> Can anyone take a look, please?
>
> Links:
> 1.
>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility/6480112?showLog=6480112_1061_895
> 2.
>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6480111?showLog=6480111_1060_894
> 3.
>
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility/6359892?showRootCauses=true=6359892_1003_909
> 4.
>
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6359893?showRootCauses=true=6359893_1003_909
> .
> 5.
>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility/6479329
> 6.
>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6479328
> 7.
>
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility/6359189?showRootCauses=true=true
> 8.
>
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6359190?showRootCauses=true=true
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: IEP-83 Thin Client Keepalive (heartbeat)

[Ivan Daschinsky]

Agree with it, it is consistent. Seems that I have suggested the same

чт, 17 февр. 2022 г., 11:05 Pavel Tupitsyn :

> I've reviewed the code again and it does not seem right to override
> user-defined heartbeat interval with a *bigger* value,
> so now I only set it to 1/3 of idleTimeout when the user-specified value is
> not already less than that.
>
> On Wed, Feb 16, 2022 at 7:19 PM Pavel Tupitsyn 
> wrote:
>
> > Ok, let's keep heartbeatInterval then.
> > I've updated the code to reflect our recent agreement, please review.
> >
> > On Tue, Feb 15, 2022 at 8:28 PM Ivan Daschinsky 
> > wrote:
> >
> >> I personally prefer heartbeatInterval
> >>
> >> вт, 15 февр. 2022 г., 18:25 Pavel Tupitsyn :
> >>
> >> > > What about "keepAlive", "keepAliveInterval" then? It looks more
> common
> >> > and matches the IEP title :)
> >> > According to Google, HeartbeatInterval has ~169K results, and
> >> > KeepAliveInterval has ~110K :)
> >> >
> >> > In my experience, both are well understood. I am equally willing to
> use
> >> any
> >> > of them.
> >> > Any other opinions?
> >> >
> >> > On Tue, Feb 15, 2022 at 6:11 PM Maksim Timonin <
> timoninma...@apache.org
> >> >
> >> > wrote:
> >> >
> >> > > What about "keepAlive", "keepAliveInterval" then? It looks more
> common
> >> > and
> >> > > matches the IEP title :)
> >> > >
> >> > > On Tue, Feb 15, 2022 at 5:54 PM Pavel Tupitsyn <
> ptupit...@apache.org>
> >> > > wrote:
> >> > >
> >> > > > To summarize, we add two properties to the ClientConfiguration:
> >> > > > bool heartbeatsEnabled = true;
> >> > > > long defaultHeartbeatInterval = 60_000; // Default 1 minute, used
> >> > > >
> >> > > > Logic:
> >> > > > if (heartbeatsEnabled) {
> >> > > >   heartbeatInterval = serverIdleTimeout > 0 ? serverIdleTimeout /
> 3
> >> :
> >> > > > defaultHeartbeatInterval;
> >> > > > }
> >> > > >
> >> > > >
> >> > > > Thoughts, objections?
> >> > > >
> >> > > > On Tue, Feb 15, 2022 at 4:32 PM Ivan Daschinsky <
> >> ivanda...@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > Pavel, sorry, i've made mistake. But current behaviour is ok for
> >> me.
> >> > > This
> >> > > > > timeout cannot be change on server side runtime. But we can
> >> simplify
> >> > > > > protocol just use one opcode and message
> >> > > > >
> >> > > > > вт, 15 февр. 2022 г., 14:54 Ivan Daschinsky <
> ivanda...@gmail.com
> >> >:
> >> > > > >
> >> > > > > > > Idle timeout can't change, why send it back with every
> >> heartbeat
> >> > > > > > response?
> >> > > > > > May be I am wrong, but from code I see this behaviour. But if
> I
> >> am
> >> > > > wrong,
> >> > > > > > this is ok behaviour for me.
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > вт, 15 февр. 2022 г. в 14:00, Pavel Tupitsyn <
> >> ptupit...@apache.org
> >> > >:
> >> > > > > >
> >> > > > > >> Ivan, I mostly agree with your proposal, except this point:
> >> > > > > >>
> >> > > > > >> > Response to heartbeat request -- is idle timeout
> >> > > > > >> Idle timeout can't change, why send it back with every
> >> heartbeat
> >> > > > > response?
> >> > > > > >>
> >> > > > > >> > possible cases with cluster restart, upgrade
> >> > > > > >> In those cases, a new connection will be established, and
> we'll
> >> > > > retrieve
> >> > > > > >> the new timeout after the handshake.
> >> > > > > >>
> >> > > > > >>
> >> > > > > >> On Tue, Feb 15, 2022 at 12:04 PM Maksim Timonin <
> >> > > > > tim

Re: IEP-83 Thin Client Keepalive (heartbeat)

[Ivan Daschinsky]

I personally prefer heartbeatInterval

вт, 15 февр. 2022 г., 18:25 Pavel Tupitsyn :

> > What about "keepAlive", "keepAliveInterval" then? It looks more common
> and matches the IEP title :)
> According to Google, HeartbeatInterval has ~169K results, and
> KeepAliveInterval has ~110K :)
>
> In my experience, both are well understood. I am equally willing to use any
> of them.
> Any other opinions?
>
> On Tue, Feb 15, 2022 at 6:11 PM Maksim Timonin 
> wrote:
>
> > What about "keepAlive", "keepAliveInterval" then? It looks more common
> and
> > matches the IEP title :)
> >
> > On Tue, Feb 15, 2022 at 5:54 PM Pavel Tupitsyn 
> > wrote:
> >
> > > To summarize, we add two properties to the ClientConfiguration:
> > > bool heartbeatsEnabled = true;
> > > long defaultHeartbeatInterval = 60_000; // Default 1 minute, used
> > >
> > > Logic:
> > > if (heartbeatsEnabled) {
> > >   heartbeatInterval = serverIdleTimeout > 0 ? serverIdleTimeout / 3 :
> > > defaultHeartbeatInterval;
> > > }
> > >
> > >
> > > Thoughts, objections?
> > >
> > > On Tue, Feb 15, 2022 at 4:32 PM Ivan Daschinsky 
> > > wrote:
> > >
> > > > Pavel, sorry, i've made mistake. But current behaviour is ok for me.
> > This
> > > > timeout cannot be change on server side runtime. But we can simplify
> > > > protocol just use one opcode and message
> > > >
> > > > вт, 15 февр. 2022 г., 14:54 Ivan Daschinsky :
> > > >
> > > > > > Idle timeout can't change, why send it back with every heartbeat
> > > > > response?
> > > > > May be I am wrong, but from code I see this behaviour. But if I am
> > > wrong,
> > > > > this is ok behaviour for me.
> > > > >
> > > > >
> > > > >
> > > > > вт, 15 февр. 2022 г. в 14:00, Pavel Tupitsyn  >:
> > > > >
> > > > >> Ivan, I mostly agree with your proposal, except this point:
> > > > >>
> > > > >> > Response to heartbeat request -- is idle timeout
> > > > >> Idle timeout can't change, why send it back with every heartbeat
> > > > response?
> > > > >>
> > > > >> > possible cases with cluster restart, upgrade
> > > > >> In those cases, a new connection will be established, and we'll
> > > retrieve
> > > > >> the new timeout after the handshake.
> > > > >>
> > > > >>
> > > > >> On Tue, Feb 15, 2022 at 12:04 PM Maksim Timonin <
> > > > timoninma...@apache.org>
> > > > >> wrote:
> > > > >>
> > > > >> > Hi Ivan,
> > > > >> >
> > > > >> > Cases you described sound reasonable to me. Then the client
> should
> > > > just
> > > > >> set
> > > > >> > up the `keepAlive` flag, and it just works.
> > > > >> >
> > > > >> > So, there are 3 branches:
> > > > >> > 1. Users don't configure keepAlive at all.
> > > > >> > 2. Users configure keepAliveHeartbeatInterval (long, ms).
> > > > >> > 3. Users configure keepAlive (boolean).
> > > > >> >
> > > > >> > AFAIU, Pavel's proposal is about covering the second case only.
> > But
> > > > >> > actually the 2nd and 3rd aren't conflicted with each other.I
> think
> > > for
> > > > >> both
> > > > >> > branches, a cluster should respond with idleTimeout value on
> every
> > > > keep
> > > > >> > alive client request. Because there are possible cases with
> > cluster
> > > > >> > restart, upgrade, etc. Clients should check every response and
> in
> > > case
> > > > >> of
> > > > >> > changed idleTimeout. For 2nd case write a WARN message, and for
> > 3rd
> > > -
> > > > >> > reconfigure themself in case of changed idleTimeout.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Tue, Feb 15, 2022 at 9:51 AM Ivan Daschinsky <
> > > ivanda...@gmail.com>
> > > > >> > wrote:
> > > > >> >

Re: IEP-83 Thin Client Keepalive (heartbeat)

[Ivan Daschinsky]

Let's think about unify two operations

Pros.
1. Just one operation.
2. Possibility to change idle timeout in runtime on cluster (using
distributed property)

Cons.
1. Extra 8 bytes (as for me, it is negligible)

As for me, less op_codes and format messages is better.

вт, 15 февр. 2022 г. в 16:32, Ivan Daschinsky :

> Pavel, sorry, i've made mistake. But current behaviour is ok for me. This
> timeout cannot be change on server side runtime. But we can simplify
> protocol just use one opcode and message
>
> вт, 15 февр. 2022 г., 14:54 Ivan Daschinsky :
>
>> > Idle timeout can't change, why send it back with every heartbeat
>> response?
>> May be I am wrong, but from code I see this behaviour. But if I am wrong,
>> this is ok behaviour for me.
>>
>>
>>
>> вт, 15 февр. 2022 г. в 14:00, Pavel Tupitsyn :
>>
>>> Ivan, I mostly agree with your proposal, except this point:
>>>
>>> > Response to heartbeat request -- is idle timeout
>>> Idle timeout can't change, why send it back with every heartbeat
>>> response?
>>>
>>> > possible cases with cluster restart, upgrade
>>> In those cases, a new connection will be established, and we'll retrieve
>>> the new timeout after the handshake.
>>>
>>>
>>> On Tue, Feb 15, 2022 at 12:04 PM Maksim Timonin >> >
>>> wrote:
>>>
>>> > Hi Ivan,
>>> >
>>> > Cases you described sound reasonable to me. Then the client should
>>> just set
>>> > up the `keepAlive` flag, and it just works.
>>> >
>>> > So, there are 3 branches:
>>> > 1. Users don't configure keepAlive at all.
>>> > 2. Users configure keepAliveHeartbeatInterval (long, ms).
>>> > 3. Users configure keepAlive (boolean).
>>> >
>>> > AFAIU, Pavel's proposal is about covering the second case only. But
>>> > actually the 2nd and 3rd aren't conflicted with each other.I think for
>>> both
>>> > branches, a cluster should respond with idleTimeout value on every keep
>>> > alive client request. Because there are possible cases with cluster
>>> > restart, upgrade, etc. Clients should check every response and in case
>>> of
>>> > changed idleTimeout. For 2nd case write a WARN message, and for 3rd -
>>> > reconfigure themself in case of changed idleTimeout.
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, Feb 15, 2022 at 9:51 AM Ivan Daschinsky 
>>> > wrote:
>>> >
>>> > > Regarding discussion here [1]
>>> > >
>>> > > I suppose that this feature, despite the fact that initial intention
>>> of
>>> > > Pavel was different, can drastically
>>> > > improve the usage pattern of thin clients and give a lot of
>>> opportunities
>>> > > if the following is done:
>>> > >
>>> > > 1. GridNioServer has a great feature -- idle timeout. If  a server
>>> did
>>> > not
>>> > > receive any from a client -- it will be kicked off.
>>> > > But there are some scenarios that make the use of this feature
>>> > > impossible:
>>> > > a. Multiple workers waiting for batch tasks and relatively low
>>> requests
>>> > > rate -- this services will be often kicked off and must reconnect.
>>> > > In order to prevent this behaviour, the user must implement a kind of
>>> > > heartbeating by himself.
>>> > > b. Quite often user may want to implement leader-follower pattern for
>>> > > services for HA, so followers also will be considered as idle.
>>> Kicking
>>> > off
>>> > > these followers
>>> > > is not acceptable, so user  should also implement heartbeating by
>>> > himself.
>>> > >
>>> > > My proposition is:
>>> > > 1. Add two flags -- enable/disable heartbeats, and very optional
>>> > heartbeat
>>> > > timeout. Set enable to true by default, timeout to default heartbeat
>>> > > timeout.
>>> > > 2. If server and client both support this feature, and heartbeats
>>> are not
>>> > > explicitly disabled on client side:
>>> > > 3. Response to heartbeat request -- is idle timeout. If idle timeout
>>> is
>>> > set
>>> > > on the server side , set heartbeat timeout to one-third of it,
>>> instead
>>> &

Re: IEP-83 Thin Client Keepalive (heartbeat)

[Ivan Daschinsky]

Pavel, sorry, i've made mistake. But current behaviour is ok for me. This
timeout cannot be change on server side runtime. But we can simplify
protocol just use one opcode and message

вт, 15 февр. 2022 г., 14:54 Ivan Daschinsky :

> > Idle timeout can't change, why send it back with every heartbeat
> response?
> May be I am wrong, but from code I see this behaviour. But if I am wrong,
> this is ok behaviour for me.
>
>
>
> вт, 15 февр. 2022 г. в 14:00, Pavel Tupitsyn :
>
>> Ivan, I mostly agree with your proposal, except this point:
>>
>> > Response to heartbeat request -- is idle timeout
>> Idle timeout can't change, why send it back with every heartbeat response?
>>
>> > possible cases with cluster restart, upgrade
>> In those cases, a new connection will be established, and we'll retrieve
>> the new timeout after the handshake.
>>
>>
>> On Tue, Feb 15, 2022 at 12:04 PM Maksim Timonin 
>> wrote:
>>
>> > Hi Ivan,
>> >
>> > Cases you described sound reasonable to me. Then the client should just
>> set
>> > up the `keepAlive` flag, and it just works.
>> >
>> > So, there are 3 branches:
>> > 1. Users don't configure keepAlive at all.
>> > 2. Users configure keepAliveHeartbeatInterval (long, ms).
>> > 3. Users configure keepAlive (boolean).
>> >
>> > AFAIU, Pavel's proposal is about covering the second case only. But
>> > actually the 2nd and 3rd aren't conflicted with each other.I think for
>> both
>> > branches, a cluster should respond with idleTimeout value on every keep
>> > alive client request. Because there are possible cases with cluster
>> > restart, upgrade, etc. Clients should check every response and in case
>> of
>> > changed idleTimeout. For 2nd case write a WARN message, and for 3rd -
>> > reconfigure themself in case of changed idleTimeout.
>> >
>> >
>> >
>> >
>> > On Tue, Feb 15, 2022 at 9:51 AM Ivan Daschinsky 
>> > wrote:
>> >
>> > > Regarding discussion here [1]
>> > >
>> > > I suppose that this feature, despite the fact that initial intention
>> of
>> > > Pavel was different, can drastically
>> > > improve the usage pattern of thin clients and give a lot of
>> opportunities
>> > > if the following is done:
>> > >
>> > > 1. GridNioServer has a great feature -- idle timeout. If  a server did
>> > not
>> > > receive any from a client -- it will be kicked off.
>> > > But there are some scenarios that make the use of this feature
>> > > impossible:
>> > > a. Multiple workers waiting for batch tasks and relatively low
>> requests
>> > > rate -- this services will be often kicked off and must reconnect.
>> > > In order to prevent this behaviour, the user must implement a kind of
>> > > heartbeating by himself.
>> > > b. Quite often user may want to implement leader-follower pattern for
>> > > services for HA, so followers also will be considered as idle. Kicking
>> > off
>> > > these followers
>> > > is not acceptable, so user  should also implement heartbeating by
>> > himself.
>> > >
>> > > My proposition is:
>> > > 1. Add two flags -- enable/disable heartbeats, and very optional
>> > heartbeat
>> > > timeout. Set enable to true by default, timeout to default heartbeat
>> > > timeout.
>> > > 2. If server and client both support this feature, and heartbeats are
>> not
>> > > explicitly disabled on client side:
>> > > 3. Response to heartbeat request -- is idle timeout. If idle timeout
>> is
>> > set
>> > > on the server side , set heartbeat timeout to one-third of it, instead
>> > set
>> > > to default or specified value.
>> > >
>> > > Pros:
>> > > 1. Easy to set up -- just flag on client side and just set timeout on
>> > > server side.
>> > > 2. Hard to configure improperly, i.e set heartbeat timeout not short
>> > enough
>> > > in order to prevent kicking out by server.
>> > > 3. If the user just wants heartbeats without setting idle timeout --
>> > > heartbeats are by default on and with reasonable timeout.
>> > >
>> > > Cons:
>> > > 1. If someone will rely on old behavior and just wants to drop his
>> > clients
>> > > on timeout -- this will not work without 

Re: IEP-83 Thin Client Keepalive (heartbeat)

[Ivan Daschinsky]

> Idle timeout can't change, why send it back with every heartbeat response?
May be I am wrong, but from code I see this behaviour. But if I am wrong,
this is ok behaviour for me.



вт, 15 февр. 2022 г. в 14:00, Pavel Tupitsyn :

> Ivan, I mostly agree with your proposal, except this point:
>
> > Response to heartbeat request -- is idle timeout
> Idle timeout can't change, why send it back with every heartbeat response?
>
> > possible cases with cluster restart, upgrade
> In those cases, a new connection will be established, and we'll retrieve
> the new timeout after the handshake.
>
>
> On Tue, Feb 15, 2022 at 12:04 PM Maksim Timonin 
> wrote:
>
> > Hi Ivan,
> >
> > Cases you described sound reasonable to me. Then the client should just
> set
> > up the `keepAlive` flag, and it just works.
> >
> > So, there are 3 branches:
> > 1. Users don't configure keepAlive at all.
> > 2. Users configure keepAliveHeartbeatInterval (long, ms).
> > 3. Users configure keepAlive (boolean).
> >
> > AFAIU, Pavel's proposal is about covering the second case only. But
> > actually the 2nd and 3rd aren't conflicted with each other.I think for
> both
> > branches, a cluster should respond with idleTimeout value on every keep
> > alive client request. Because there are possible cases with cluster
> > restart, upgrade, etc. Clients should check every response and in case of
> > changed idleTimeout. For 2nd case write a WARN message, and for 3rd -
> > reconfigure themself in case of changed idleTimeout.
> >
> >
> >
> >
> > On Tue, Feb 15, 2022 at 9:51 AM Ivan Daschinsky 
> > wrote:
> >
> > > Regarding discussion here [1]
> > >
> > > I suppose that this feature, despite the fact that initial intention of
> > > Pavel was different, can drastically
> > > improve the usage pattern of thin clients and give a lot of
> opportunities
> > > if the following is done:
> > >
> > > 1. GridNioServer has a great feature -- idle timeout. If  a server did
> > not
> > > receive any from a client -- it will be kicked off.
> > > But there are some scenarios that make the use of this feature
> > > impossible:
> > > a. Multiple workers waiting for batch tasks and relatively low requests
> > > rate -- this services will be often kicked off and must reconnect.
> > > In order to prevent this behaviour, the user must implement a kind of
> > > heartbeating by himself.
> > > b. Quite often user may want to implement leader-follower pattern for
> > > services for HA, so followers also will be considered as idle. Kicking
> > off
> > > these followers
> > > is not acceptable, so user  should also implement heartbeating by
> > himself.
> > >
> > > My proposition is:
> > > 1. Add two flags -- enable/disable heartbeats, and very optional
> > heartbeat
> > > timeout. Set enable to true by default, timeout to default heartbeat
> > > timeout.
> > > 2. If server and client both support this feature, and heartbeats are
> not
> > > explicitly disabled on client side:
> > > 3. Response to heartbeat request -- is idle timeout. If idle timeout is
> > set
> > > on the server side , set heartbeat timeout to one-third of it, instead
> > set
> > > to default or specified value.
> > >
> > > Pros:
> > > 1. Easy to set up -- just flag on client side and just set timeout on
> > > server side.
> > > 2. Hard to configure improperly, i.e set heartbeat timeout not short
> > enough
> > > in order to prevent kicking out by server.
> > > 3. If the user just wants heartbeats without setting idle timeout --
> > > heartbeats are by default on and with reasonable timeout.
> > >
> > > Cons:
> > > 1. If someone will rely on old behavior and just wants to drop his
> > clients
> > > on timeout -- this will not work without reconfiguring, he should
> disable
> > > heartbeats.
> > > But I cannot even imagine that someone will find this behaviour
> > desirable.
> > > I strongly believe that this behaviour prevents users from using
> > > idleTimeout on server side.
> > >
> > > [1] --
> https://github.com/apache/ignite/pull/9817#discussion_r805628955
> > >
> > > пт, 11 февр. 2022 г. в 10:58, Pavel Tupitsyn :
> > >
> > > > I've prepared a PR, please have a look:
> > > > https://github.com/apache/ignite/pull/9817
> > > >
> > > > On M

Re: IEP-83 Thin Client Keepalive (heartbeat)

[Ivan Daschinsky]

Regarding discussion here [1]

I suppose that this feature, despite the fact that initial intention of
Pavel was different, can drastically
improve the usage pattern of thin clients and give a lot of opportunities
if the following is done:

1. GridNioServer has a great feature -- idle timeout. If  a server did not
receive any from a client -- it will be kicked off.
But there are some scenarios that make the use of this feature
impossible:
a. Multiple workers waiting for batch tasks and relatively low requests
rate -- this services will be often kicked off and must reconnect.
In order to prevent this behaviour, the user must implement a kind of
heartbeating by himself.
b. Quite often user may want to implement leader-follower pattern for
services for HA, so followers also will be considered as idle. Kicking off
these followers
is not acceptable, so user  should also implement heartbeating by himself.

My proposition is:
1. Add two flags -- enable/disable heartbeats, and very optional heartbeat
timeout. Set enable to true by default, timeout to default heartbeat
timeout.
2. If server and client both support this feature, and heartbeats are not
explicitly disabled on client side:
3. Response to heartbeat request -- is idle timeout. If idle timeout is set
on the server side , set heartbeat timeout to one-third of it, instead set
to default or specified value.

Pros:
1. Easy to set up -- just flag on client side and just set timeout on
server side.
2. Hard to configure improperly, i.e set heartbeat timeout not short enough
in order to prevent kicking out by server.
3. If the user just wants heartbeats without setting idle timeout --
heartbeats are by default on and with reasonable timeout.

Cons:
1. If someone will rely on old behavior and just wants to drop his clients
on timeout -- this will not work without reconfiguring, he should disable
heartbeats.
But I cannot even imagine that someone will find this behaviour desirable.
I strongly believe that this behaviour prevents users from using
idleTimeout on server side.

[1] -- https://github.com/apache/ignite/pull/9817#discussion_r805628955

пт, 11 февр. 2022 г. в 10:58, Pavel Tupitsyn :

> I've prepared a PR, please have a look:
> https://github.com/apache/ignite/pull/9817
>
> On Mon, Feb 7, 2022 at 6:37 PM Ivan Daschinsky 
> wrote:
>
> > I see potential in this feature, especially if we use something like
> > continuous query. Stale clients can consume a lot of resources and it is
> > worth kick these clients out.
> >
> > пн, 7 февр. 2022 г. в 18:25, Pavel Tupitsyn :
> >
> > > > If we use new approach, we can reduce this timeout. But this can
> affect
> > > old clients.
> > >
> > > idleTimeout is disabled by default, we are not going to change this.
> > >
> > > > Also, let's think about that sending heartbeats and interval of
> sending
> > > > heartbeats could be calculated on the server side (i.e. one third of
> > idle
> > > > timeout) and sent to the client during handshake.
> > > > Also we can introduce something like a negotiation mechanism as in
> > > > zookeeper.
> > >
> > > I tend to agree with Maksim here, let's keep it simple and explicit.
> > > Log a warning, but don't do anything clever.
> > >
> > > On Mon, Feb 7, 2022 at 6:15 PM Ivan Daschinsky 
> > > wrote:
> > >
> > > > >> idleTimeout already exists, I don't think we should change the way
> > it
> > > > works (or did I misunderstand you?)
> > > > If we use new approach, we can reduce this timeout. But this can
> affect
> > > old
> > > > clients.
> > > >
> > > >
> > > > Also, let's think about that sending heartbeats and interval of
> sending
> > > > heartbeats could be calculated on the server side (i.e. one third of
> > idle
> > > > timeout) and sent to the client
> > > > during handshake.
> > > > Also we can introduce something like a negotiation mechanism as in
> > > > zookeeper.
> > > >
> > > >
> > > > пн, 7 февр. 2022 г. в 18:05, Pavel Tupitsyn :
> > > >
> > > > > Igor,
> > > > >
> > > > > > Maybe clients should pass this information on to the handshake.
> > > > >
> > > > > Do you think we should log a mismatched timeout warning on the
> > server,
> > > > not
> > > > > on the client?
> > > > > Or should we do both?
> > > > >
> > > > >
> > > > > I've updated the proposal with OP_GET_IDLE_TIMEOUT and some other
> > > details
> > > > > dis

Re: [ANNOUNCE] Welcome Pavel Pereslegin as a new committer

[Ivan Daschinsky]

Congrats, Pasha!

чт, 10 февр. 2022 г. в 18:16, Maxim Muzafarov :

> The Project Management Committee (PMC) for Apache Ignite has invited
> Pavel Pereslegin to become a committer and we are pleased to announce that
> he has accepted.
>
> He made a lot of major contributions to the Apache Ignite codebase
> like a snapshot restore procedure, batch update operation to the
> PageMemory, TDE cache key rotation procedure, Service context
> injection and etc.
>
> Being a committer enables easier contribution to the project since there is
> no need to go via the patch submission process. This should enable better
> productivity.
>
> Please join me in welcoming Pavel, and congratulating him on the new role
> in
> the Apache Ignite Community.
>
>
> Best Regards,
> Maxim Muzafarov
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSSION] Redis and memcached protocol support.

[Ivan Daschinsky]

As for me, I believe that this should be removed. We have already proven
binary protocol that is under heavy use.

ср, 9 февр. 2022 г. в 15:11, Maxim Muzafarov :

> Hello,
>
> From my point of view, it's better to reduce the scope of features to
> be supported and focus on those ones that a really important for
> production e.g. Calcite for Ignite 2.x. However, talking in terms of
> open-source development it's better to find a volunteer who will fix
> all the issues you describe.
>
> On Tue, 8 Feb 2022 at 14:27, Ivan Daschinsky  wrote:
> >
> > Igniters, I'd like to discuss the future of this functionality in Apache
> > Ignite
> >
> > Today this functionality seems to be unusable
> > 1. It is limited (especially redis)
> > 2. It doesn't support HA (redis sentinel or redis cluster)
> > 3. Nobody maintains it and even nobody fixes bugs. (i.e. [1] is not
> merged
> > for years).
> >
> > If we want to support redis protocol, we should rewrite it and add HA
> > features.
> > Otherwise, I suppose that we should consider complete removal of this
> code
> > from codebase.
> >
> > WDYT?
> >
> >
> > [1] -- https://issues.apache.org/jira/browse/IGNITE-7153
>


-- 
Sincerely yours, Ivan Daschinskiy

[DISCUSSION] Redis and memcached protocol support.

[Ivan Daschinsky]

Igniters, I'd like to discuss the future of this functionality in Apache
Ignite

Today this functionality seems to be unusable
1. It is limited (especially redis)
2. It doesn't support HA (redis sentinel or redis cluster)
3. Nobody maintains it and even nobody fixes bugs. (i.e. [1] is not merged
for years).

If we want to support redis protocol, we should rewrite it and add HA
features.
Otherwise, I suppose that we should consider complete removal of this code
from codebase.

WDYT?


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

Re: [DISCUSSION] Shmem removal.

[Ivan Daschinsky]

Patch has been reviewed by Andrey Mashenkov and Max Muzafarov and approved.
If nobody disagrees, I will merge it in a few hours.

пн, 7 февр. 2022 г. в 12:21, Ivan Daschinsky :

> Patch is ready for review
>
> пт, 4 февр. 2022 г. в 14:45, Ivan Daschinsky :
>
>> https://issues.apache.org/jira/browse/IGNITE-16480 -- I've filed ticked.
>>
>> пт, 7 янв. 2022 г. в 23:44, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>>
>>> Doesn't look like there are any objections - it's been a month since you
>>> started this thread. Let's create a ticket.
>>>
>>> -Val
>>>
>>>
>>> On Thu, Jan 6, 2022 at 1:22 AM Ivan Daschinsky 
>>> wrote:
>>>
>>> > Hi, Val. My plan was to file a specific ticket after discussion. If the
>>> > community agrees that this module should be removed, I will file a
>>> specific
>>> > ticket for it.
>>> >
>>> > ср, 5 янв. 2022 г., 22:26 Valentin Kulichenko <
>>> > valentin.kuliche...@gmail.com
>>> > >:
>>> >
>>> > > Hi Ivan,
>>> > >
>>> > > Do we have a ticket for this?
>>> > >
>>> > > -Val
>>> > >
>>> > > On Fri, Dec 3, 2021 at 10:58 AM Valentin Kulichenko <
>>> > > valentin.kuliche...@gmail.com> wrote:
>>> > >
>>> > > > I think we can safely remove it.
>>> > > >
>>> > > > -Val
>>> > > >
>>> > > > On Thu, Dec 2, 2021 at 11:52 PM Ivan Daschinsky <
>>> ivanda...@gmail.com>
>>> > > > wrote:
>>> > > >
>>> > > >> Hi, igniters.
>>> > > >>
>>> > > >> Recently I've discovered one fact
>>> > > >> 1. GridShmemCommunicationClient and all shmem functionality are
>>> broken
>>> > > >> since 2.10. In master it is broken since August 2020. And nobody
>>> have
>>> > > >> noticed it, only one thread in user list.
>>> > > >> 2. We have source code for native JNI library (that is shipped in
>>> > > >> ignite-shmem.jar), but we never built it since 2015.
>>> > > >> 3. This code is of questionable quality, contains outdated
>>> internal
>>> > gcc
>>> > > >> api
>>> > > >> (__sync builtins, now deprecated in favour of __atomic builtins
>>> in gcc
>>> > > and
>>> > > >> is not advisable to use since C++ 11). It contains a lot of
>>> autotool
>>> > > mess,
>>> > > >> while just one CMakeFile.txt is enough to build the same
>>> > > >> 4. This code doesn't even compile on modern gcc (gcc 9.3.0 namely)
>>> > > >>
>>> > > >> We have 2 options
>>> > > >> 1. If this concept is useful, we (for example I can do it) should
>>> > > rewrite
>>> > > >> native part,
>>> > > >> a. Use C++ 11 and header-only boost.interprocess [1]
>>> > > >> b. Build it regularly with CMake and incorporate build in regular
>>> TC
>>> > > runs
>>> > > >> (via maven-cmake-plugin,
>>> > > >> see for example my numa-allocator [2]).
>>> > > >> 2. If this concept and functionality is not useful, we should
>>> remove
>>> > it,
>>> > > >> may be even in 2.12
>>> > > >>
>>> > > >>
>>> > > >> [1] --
>>> > https://www.boost.org/doc/libs/1_77_0/doc/html/interprocess.html
>>> > > >> [2] --
>>> > > >>
>>> > > >>
>>> > >
>>> >
>>> https://github.com/apache/ignite/pull/9569/files#diff-77baf2378aa83911a8c3091814db3ff60b7bf328c4ab4850f707717ed96f3d92
>>> > > >> --
>>> > > >> Sincerely yours, Ivan Daschinskiy
>>> > > >>
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>> --
>> Sincerely yours, Ivan Daschinskiy
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: IEP-83 Thin Client Keepalive (heartbeat)

[Ivan Daschinsky]

I see potential in this feature, especially if we use something like
continuous query. Stale clients can consume a lot of resources and it is
worth kick these clients out.

пн, 7 февр. 2022 г. в 18:25, Pavel Tupitsyn :

> > If we use new approach, we can reduce this timeout. But this can affect
> old clients.
>
> idleTimeout is disabled by default, we are not going to change this.
>
> > Also, let's think about that sending heartbeats and interval of sending
> > heartbeats could be calculated on the server side (i.e. one third of idle
> > timeout) and sent to the client during handshake.
> > Also we can introduce something like a negotiation mechanism as in
> > zookeeper.
>
> I tend to agree with Maksim here, let's keep it simple and explicit.
> Log a warning, but don't do anything clever.
>
> On Mon, Feb 7, 2022 at 6:15 PM Ivan Daschinsky 
> wrote:
>
> > >> idleTimeout already exists, I don't think we should change the way it
> > works (or did I misunderstand you?)
> > If we use new approach, we can reduce this timeout. But this can affect
> old
> > clients.
> >
> >
> > Also, let's think about that sending heartbeats and interval of sending
> > heartbeats could be calculated on the server side (i.e. one third of idle
> > timeout) and sent to the client
> > during handshake.
> > Also we can introduce something like a negotiation mechanism as in
> > zookeeper.
> >
> >
> > пн, 7 февр. 2022 г. в 18:05, Pavel Tupitsyn :
> >
> > > Igor,
> > >
> > > > Maybe clients should pass this information on to the handshake.
> > >
> > > Do you think we should log a mismatched timeout warning on the server,
> > not
> > > on the client?
> > > Or should we do both?
> > >
> > >
> > > I've updated the proposal with OP_GET_IDLE_TIMEOUT and some other
> details
> > > discussed above.
> > >
> > > On Mon, Feb 7, 2022 at 5:42 PM Igor Sapego  wrote:
> > >
> > > > Feature seems useful for me as it makes connection management more
> > robust
> > > > and
> > > > predictable.
> > > >
> > > > I agree with Pavel, that we should print warning when heartbeat
> period
> > is
> > > > larger than
> > > > idle timeout, but I see a problem here as idle timeout is configured
> on
> > > > server and is not
> > > > known to clients, while heartbeats configured on clients and their
> > period
> > > > is not known
> > > > to the server. Maybe clients should pass this information on to the
> > > > handshake.
> > > >
> > > > Regarding Python and PHP clients - can not we use some kind of timers
> > to
> > > > implement
> > > > this feature?
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Mon, Feb 7, 2022 at 5:23 PM Pavel Tupitsyn 
> > > > wrote:
> > > >
> > > > > Maksim, agree. Let's not be too clever and only log a warning.
> > > > >
> > > > > On Mon, Feb 7, 2022 at 5:23 PM Pavel Tupitsyn <
> ptupit...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Ivan, idleTimeout already exists, I don't think we should change
> > the
> > > > way
> > > > > > it works (or did I misunderstand you?)
> > > > > >
> > > > > > Of course, enabling heartbeats means that otherwise idle clients
> > will
> > > > no
> > > > > > longer be disconnected by the server.
> > > > > > I think we should cross-link those properties in the
> documentation
> > > and
> > > > > > explain this behavior.
> > > > > >
> > > > > > On Mon, Feb 7, 2022 at 4:39 PM Ivan Daschinsky <
> > ivanda...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> >>3. Already implemented: when
> > > > ClientConnectorConfiguration#idleTimeout
> > > > > is
> > > > > >> not zero, server disconnects idle clients
> > > > > >> >>
> > > > > >> But I suppose it would be great to have:
> > > > > >> 1. If client supports keep alive, use idleTimeout
> > > > > >> 2. If not, do not use it.
> > > > > >>
> > > > > >> But I am not sure if it is cor

Re: IEP-83 Thin Client Keepalive (heartbeat)

[Ivan Daschinsky]

>> idleTimeout already exists, I don't think we should change the way it
works (or did I misunderstand you?)
If we use new approach, we can reduce this timeout. But this can affect old
clients.


Also, let's think about that sending heartbeats and interval of sending
heartbeats could be calculated on the server side (i.e. one third of idle
timeout) and sent to the client
during handshake.
Also we can introduce something like a negotiation mechanism as in
zookeeper.


пн, 7 февр. 2022 г. в 18:05, Pavel Tupitsyn :

> Igor,
>
> > Maybe clients should pass this information on to the handshake.
>
> Do you think we should log a mismatched timeout warning on the server, not
> on the client?
> Or should we do both?
>
>
> I've updated the proposal with OP_GET_IDLE_TIMEOUT and some other details
> discussed above.
>
> On Mon, Feb 7, 2022 at 5:42 PM Igor Sapego  wrote:
>
> > Feature seems useful for me as it makes connection management more robust
> > and
> > predictable.
> >
> > I agree with Pavel, that we should print warning when heartbeat period is
> > larger than
> > idle timeout, but I see a problem here as idle timeout is configured on
> > server and is not
> > known to clients, while heartbeats configured on clients and their period
> > is not known
> > to the server. Maybe clients should pass this information on to the
> > handshake.
> >
> > Regarding Python and PHP clients - can not we use some kind of timers to
> > implement
> > this feature?
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, Feb 7, 2022 at 5:23 PM Pavel Tupitsyn 
> > wrote:
> >
> > > Maksim, agree. Let's not be too clever and only log a warning.
> > >
> > > On Mon, Feb 7, 2022 at 5:23 PM Pavel Tupitsyn 
> > > wrote:
> > >
> > > > Ivan, idleTimeout already exists, I don't think we should change the
> > way
> > > > it works (or did I misunderstand you?)
> > > >
> > > > Of course, enabling heartbeats means that otherwise idle clients will
> > no
> > > > longer be disconnected by the server.
> > > > I think we should cross-link those properties in the documentation
> and
> > > > explain this behavior.
> > > >
> > > > On Mon, Feb 7, 2022 at 4:39 PM Ivan Daschinsky 
> > > > wrote:
> > > >
> > > >> >>3. Already implemented: when
> > ClientConnectorConfiguration#idleTimeout
> > > is
> > > >> not zero, server disconnects idle clients
> > > >> >>
> > > >> But I suppose it would be great to have:
> > > >> 1. If client supports keep alive, use idleTimeout
> > > >> 2. If not, do not use it.
> > > >>
> > > >> But I am not sure if it is correct or not.
> > > >>
> > > >> пн, 7 февр. 2022 г. в 16:01, Maksim Timonin <
> timoninma...@apache.org
> > >:
> > > >>
> > > >> > I believe explicit is better than implicit :) Also in case of
> > dynamic
> > > >> > calculation of timeout, it can change dynamically, for example
> > > >> restarting a
> > > >> > cluster with different configuration should reconfigure clients
> too.
> > > >> Looks
> > > >> > complicated.
> > > >> >
> > > >> > My vote for WARN + javadocs with mention of this issue.
> > > >> >
> > > >> > On Mon, Feb 7, 2022 at 3:51 PM Pavel Tupitsyn <
> ptupit...@apache.org
> > >
> > > >> > wrote:
> > > >> >
> > > >> > > > WDYT, should we add a WARN message for clients that configure
> > > >> > > > keepAliveTimeout greater than idleTimeout on the server side?
> > > >> > >
> > > >> > > I think we should either log a WARN, or retrieve idleTimeout
> from
> > > >> server
> > > >> > > and configure heartbeatTimeout accordingly (e.g. divide by 2).
> > > >> > > Thoughts?
> > > >> > >
> > > >> > > On Mon, Feb 7, 2022 at 3:14 PM Maksim Timonin <
> > > >> timoninma...@apache.org>
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Hi Pavel,
> > > >> > > >
> > > >> > > > Thanks for the links. Yes, I forgot that the flag of changed
> > > >> topology
> > &g

Re: IEP-83 Thin Client Keepalive (heartbeat)

[Ivan Daschinsky]

>>3. Already implemented: when ClientConnectorConfiguration#idleTimeout is
not zero, server disconnects idle clients
>>
But I suppose it would be great to have:
1. If client supports keep alive, use idleTimeout
2. If not, do not use it.

But I am not sure if it is correct or not.

пн, 7 февр. 2022 г. в 16:01, Maksim Timonin :

> I believe explicit is better than implicit :) Also in case of dynamic
> calculation of timeout, it can change dynamically, for example restarting a
> cluster with different configuration should reconfigure clients too. Looks
> complicated.
>
> My vote for WARN + javadocs with mention of this issue.
>
> On Mon, Feb 7, 2022 at 3:51 PM Pavel Tupitsyn 
> wrote:
>
> > > WDYT, should we add a WARN message for clients that configure
> > > keepAliveTimeout greater than idleTimeout on the server side?
> >
> > I think we should either log a WARN, or retrieve idleTimeout from server
> > and configure heartbeatTimeout accordingly (e.g. divide by 2).
> > Thoughts?
> >
> > On Mon, Feb 7, 2022 at 3:14 PM Maksim Timonin 
> > wrote:
> >
> > > Hi Pavel,
> > >
> > > Thanks for the links. Yes, I forgot that the flag of changed topology
> is
> > > lazy. Also I missed that the keepAlive setting is configured on the
> > client
> > > side (alternatively to idleTimeout that is on the server side).
> > >
> > > Now I understand, this feature can be helpful then. Every client can
> > > configure itself in case it's possible to be idle sometimes, and choose
> > > an appropriate timeout by itself too. And by default the feature should
> > be
> > > disabled.
> > >
> > > WDYT, should we add a WARN message for clients that configure
> > > keepAliveTimeout greater than idleTimeout on the server side?
> > >
> > >
> > >
> > > On Mon, Feb 7, 2022 at 1:05 PM Pavel Tupitsyn 
> > > wrote:
> > >
> > > > Ivan,
> > > >
> > > > I suggest the following:
> > > >
> > > > 1. Server sends KEEP_ALIVE feature flag, which means it accepts
> > > > OP_KEEP_ALIVE empty message
> > > > 2. Client sends OP_KEEP_ALIVE when the connection is idle for a
> > > > certain period of time
> > > > 3. Already implemented: when ClientConnectorConfiguration#idleTimeout
> > is
> > > > not zero, server disconnects idle clients
> > > >
> > > > This way we don't need server->client keepalives, as you correctly
> > noted.
> > > >
> > > > On Mon, Feb 7, 2022 at 12:43 PM Ivan Daschinsky  >
> > > > wrote:
> > > >
> > > > > Pavel, I suppose that ideally:
> > > > > 1. Client send in handshake flag, that it supports KEEP_ALIVE
> feature
> > > and
> > > > > server takes it into account.
> > > > > 2. Each request of client can be considered as keep-alive ping.
> > > > > 3. Client send failure should be processed using retry policy.
> > > > > 4. Server should not send keep-alive packets, it is redundant, but
> > > server
> > > > > should track requests from client and if there is no requests from
> > > client
> > > > > with KEEP_ALIVE feature,
> > > > > automatically close connection and free resources.
> > > > >
> > > > > Similar approach is used in zookeeper clients.
> > > > >
> > > > > пн, 7 февр. 2022 г. в 12:24, Pavel Tupitsyn  >:
> > > > >
> > > > > > Ivan,
> > > > > >
> > > > > > Ideally, the check should come from both sides.
> > > > > > - Client periodically sends keepalive to server
> > > > > > - Server periodically sends keepalive to client
> > > > > >
> > > > > > Feature flags will be added accordingly, so it is not necessary
> to
> > > > > > implement this in all thin clients.
> > > > > >
> > > > > > On Mon, Feb 7, 2022 at 11:43 AM Ivan Daschinsky <
> > ivanda...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I suppose it is great idea, but this functionality can be hard
> to
> > > > > > implement
> > > > > > > for some platforms. I.e. sync python client or php (there is no
> > > real
> > > > > > > multithreading for python (GIL) and php is single threaded by
> >

Re: IEP-83 Thin Client Keepalive (heartbeat)

[Ivan Daschinsky]

Pavel, I suppose that ideally:
1. Client send in handshake flag, that it supports KEEP_ALIVE feature and
server takes it into account.
2. Each request of client can be considered as keep-alive ping.
3. Client send failure should be processed using retry policy.
4. Server should not send keep-alive packets, it is redundant, but server
should track requests from client and if there is no requests from client
with KEEP_ALIVE feature,
automatically close connection and free resources.

Similar approach is used in zookeeper clients.

пн, 7 февр. 2022 г. в 12:24, Pavel Tupitsyn :

> Ivan,
>
> Ideally, the check should come from both sides.
> - Client periodically sends keepalive to server
> - Server periodically sends keepalive to client
>
> Feature flags will be added accordingly, so it is not necessary to
> implement this in all thin clients.
>
> On Mon, Feb 7, 2022 at 11:43 AM Ivan Daschinsky 
> wrote:
>
> > I suppose it is great idea, but this functionality can be hard to
> implement
> > for some platforms. I.e. sync python client or php (there is no real
> > multithreading for python (GIL) and php is single threaded by design).
> But
> > for async clients it is not very hard to implement. Nevertheless, this
> > feature should be optional, because of possible technical limitations.
> >
> > Pavel, is this check mostly for client side? Or servers can do some
> actions
> > if there is no activity from thin client (i.e. closing context and free
> > resources such as queries' handles and so on?)
> >
> > пн, 7 февр. 2022 г. в 11:09, Pavel Tupitsyn :
> >
> > > Hi Maksim,
> > >
> > >
> > > > half-state is a possible situation when an Ignite node goes down or
> > > somehow removes connection to a thin client
> > >
> > > Half-open state is also possible when, for example, an intermediate
> > router
> > > is rebooted [1].
> > >
> > > This is what we seem to have encountered with one of our customers -
> they
> > > have a stable cluster, and long-living (multiple days) thin client
> > > connections which can be idle for some time.
> > > And only when we send some data on such an idle connection do we
> discover
> > > that it is broken.
> > >
> > >
> > > > But with enabled (true by default) partitionAwareness feature clients
> > can
> > > be notified about topology changes
> > >
> > > Partition awareness is a "lazy" notification in a form of a response
> > > message flag [2].
> > > You won't get one on an idle connection.
> > >
> > >
> > > > the connections are removed on the server side by client idle timeout
> > >
> > > Idle timeout is disabled by default.
> > >
> > >
> > > > is it OK to keep such connections alive for a long time
> > >
> > > I think it is up to the user.
> > >
> > >
> > > > in the case of partition awareness features it can lead to wasting
> TCP
> > > sockets on Ignite nodes, can't it
> > >
> > > Can you please elaborate?
> > >
> > >
> > > [1]
> > >
> >
> https://blog.stephencleary.com/2009/05/detection-of-half-open-dropped.html
> > > [2]
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+Thin+Clients
> > >
> > > On Fri, Feb 4, 2022 at 4:01 PM Maksim Timonin  >
> > > wrote:
> > >
> > > > Hi Pavel,
> > > >
> > > > Thanks for starting this thread! Can I ask some questions here to get
> > the
> > > > feature more clearly?
> > > >
> > > > As I understand it correctly, half-state is a possible situation when
> > an
> > > > Ignite node goes down or somehow removes connection to a thin client.
> > But
> > > > with enabled (true by default) partitionAwareness feature clients can
> > be
> > > > notified about topology changes. So, there are possible cases:
> > > > 1. ThinClient connects to a single node.
> > > > 2. Ignite node removes connection from itself.
> > > >
> > > > I like the idea for the case with a single node, as it helps fail
> fast.
> > > > But is it OK to connect a client to a single node only?
> > > >
> > > > For the second one: you mention that a case for the second option is
> > > > "Long-living and mostly idle connections are especially susceptible
> to
> > > this

Re: [DISCUSSION] Shmem removal.

[Ivan Daschinsky]

Patch is ready for review

пт, 4 февр. 2022 г. в 14:45, Ivan Daschinsky :

> https://issues.apache.org/jira/browse/IGNITE-16480 -- I've filed ticked.
>
> пт, 7 янв. 2022 г. в 23:44, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
>> Doesn't look like there are any objections - it's been a month since you
>> started this thread. Let's create a ticket.
>>
>> -Val
>>
>>
>> On Thu, Jan 6, 2022 at 1:22 AM Ivan Daschinsky 
>> wrote:
>>
>> > Hi, Val. My plan was to file a specific ticket after discussion. If the
>> > community agrees that this module should be removed, I will file a
>> specific
>> > ticket for it.
>> >
>> > ср, 5 янв. 2022 г., 22:26 Valentin Kulichenko <
>> > valentin.kuliche...@gmail.com
>> > >:
>> >
>> > > Hi Ivan,
>> > >
>> > > Do we have a ticket for this?
>> > >
>> > > -Val
>> > >
>> > > On Fri, Dec 3, 2021 at 10:58 AM Valentin Kulichenko <
>> > > valentin.kuliche...@gmail.com> wrote:
>> > >
>> > > > I think we can safely remove it.
>> > > >
>> > > > -Val
>> > > >
>> > > > On Thu, Dec 2, 2021 at 11:52 PM Ivan Daschinsky <
>> ivanda...@gmail.com>
>> > > > wrote:
>> > > >
>> > > >> Hi, igniters.
>> > > >>
>> > > >> Recently I've discovered one fact
>> > > >> 1. GridShmemCommunicationClient and all shmem functionality are
>> broken
>> > > >> since 2.10. In master it is broken since August 2020. And nobody
>> have
>> > > >> noticed it, only one thread in user list.
>> > > >> 2. We have source code for native JNI library (that is shipped in
>> > > >> ignite-shmem.jar), but we never built it since 2015.
>> > > >> 3. This code is of questionable quality, contains outdated internal
>> > gcc
>> > > >> api
>> > > >> (__sync builtins, now deprecated in favour of __atomic builtins in
>> gcc
>> > > and
>> > > >> is not advisable to use since C++ 11). It contains a lot of
>> autotool
>> > > mess,
>> > > >> while just one CMakeFile.txt is enough to build the same
>> > > >> 4. This code doesn't even compile on modern gcc (gcc 9.3.0 namely)
>> > > >>
>> > > >> We have 2 options
>> > > >> 1. If this concept is useful, we (for example I can do it) should
>> > > rewrite
>> > > >> native part,
>> > > >> a. Use C++ 11 and header-only boost.interprocess [1]
>> > > >> b. Build it regularly with CMake and incorporate build in regular
>> TC
>> > > runs
>> > > >> (via maven-cmake-plugin,
>> > > >> see for example my numa-allocator [2]).
>> > > >> 2. If this concept and functionality is not useful, we should
>> remove
>> > it,
>> > > >> may be even in 2.12
>> > > >>
>> > > >>
>> > > >> [1] --
>> > https://www.boost.org/doc/libs/1_77_0/doc/html/interprocess.html
>> > > >> [2] --
>> > > >>
>> > > >>
>> > >
>> >
>> https://github.com/apache/ignite/pull/9569/files#diff-77baf2378aa83911a8c3091814db3ff60b7bf328c4ab4850f707717ed96f3d92
>> > > >> --
>> > > >> Sincerely yours, Ivan Daschinskiy
>> > > >>
>> > > >
>> > >
>> >
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: IEP-83 Thin Client Keepalive (heartbeat)

[Ivan Daschinsky]

I suppose it is great idea, but this functionality can be hard to implement
for some platforms. I.e. sync python client or php (there is no real
multithreading for python (GIL) and php is single threaded by design). But
for async clients it is not very hard to implement. Nevertheless, this
feature should be optional, because of possible technical limitations.

Pavel, is this check mostly for client side? Or servers can do some actions
if there is no activity from thin client (i.e. closing context and free
resources such as queries' handles and so on?)

пн, 7 февр. 2022 г. в 11:09, Pavel Tupitsyn :

> Hi Maksim,
>
>
> > half-state is a possible situation when an Ignite node goes down or
> somehow removes connection to a thin client
>
> Half-open state is also possible when, for example, an intermediate router
> is rebooted [1].
>
> This is what we seem to have encountered with one of our customers - they
> have a stable cluster, and long-living (multiple days) thin client
> connections which can be idle for some time.
> And only when we send some data on such an idle connection do we discover
> that it is broken.
>
>
> > But with enabled (true by default) partitionAwareness feature clients can
> be notified about topology changes
>
> Partition awareness is a "lazy" notification in a form of a response
> message flag [2].
> You won't get one on an idle connection.
>
>
> > the connections are removed on the server side by client idle timeout
>
> Idle timeout is disabled by default.
>
>
> > is it OK to keep such connections alive for a long time
>
> I think it is up to the user.
>
>
> > in the case of partition awareness features it can lead to wasting TCP
> sockets on Ignite nodes, can't it
>
> Can you please elaborate?
>
>
> [1]
> https://blog.stephencleary.com/2009/05/detection-of-half-open-dropped.html
> [2]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+Thin+Clients
>
> On Fri, Feb 4, 2022 at 4:01 PM Maksim Timonin 
> wrote:
>
> > Hi Pavel,
> >
> > Thanks for starting this thread! Can I ask some questions here to get the
> > feature more clearly?
> >
> > As I understand it correctly, half-state is a possible situation when an
> > Ignite node goes down or somehow removes connection to a thin client. But
> > with enabled (true by default) partitionAwareness feature clients can be
> > notified about topology changes. So, there are possible cases:
> > 1. ThinClient connects to a single node.
> > 2. Ignite node removes connection from itself.
> >
> > I like the idea for the case with a single node, as it helps fail fast.
> > But is it OK to connect a client to a single node only?
> >
> > For the second one: you mention that a case for the second option is
> > "Long-living and mostly idle connections are especially susceptible to
> this
> > behavior". If I understand correctly the connections are removed on the
> > server side by client idle timeout. Can we just configure the idle
> timeout
> > for cases where we really need keeping alive idle connections? Are there
> > any other cases with unexpectedly dropped connections?
> >
> > I'm wondering is it OK to keep such connections alive for a long time?
> > Also in the case of partition awareness features it can lead to wasting
> TCP
> > sockets on Ignite nodes, can't it?
> >
> > Thanks!
> >
> >
> >
> >
> >
> >
> > On Thu, Feb 3, 2022 at 2:24 PM Pavel Tupitsyn 
> > wrote:
> >
> >> Igniters,
> >>
> >> Please review the proposal to add heartbeat messages to the thin client
> >> protocol (both 2.x and 3.x) and let me know your thoughts:
> >>
> >>
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-83+Thin+Client+Keepalive
> >>
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSSION] Shmem removal.

[Ivan Daschinsky]

https://issues.apache.org/jira/browse/IGNITE-16480 -- I've filed ticked.

пт, 7 янв. 2022 г. в 23:44, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> Doesn't look like there are any objections - it's been a month since you
> started this thread. Let's create a ticket.
>
> -Val
>
>
> On Thu, Jan 6, 2022 at 1:22 AM Ivan Daschinsky 
> wrote:
>
> > Hi, Val. My plan was to file a specific ticket after discussion. If the
> > community agrees that this module should be removed, I will file a
> specific
> > ticket for it.
> >
> > ср, 5 янв. 2022 г., 22:26 Valentin Kulichenko <
> > valentin.kuliche...@gmail.com
> > >:
> >
> > > Hi Ivan,
> > >
> > > Do we have a ticket for this?
> > >
> > > -Val
> > >
> > > On Fri, Dec 3, 2021 at 10:58 AM Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > I think we can safely remove it.
> > > >
> > > > -Val
> > > >
> > > > On Thu, Dec 2, 2021 at 11:52 PM Ivan Daschinsky  >
> > > > wrote:
> > > >
> > > >> Hi, igniters.
> > > >>
> > > >> Recently I've discovered one fact
> > > >> 1. GridShmemCommunicationClient and all shmem functionality are
> broken
> > > >> since 2.10. In master it is broken since August 2020. And nobody
> have
> > > >> noticed it, only one thread in user list.
> > > >> 2. We have source code for native JNI library (that is shipped in
> > > >> ignite-shmem.jar), but we never built it since 2015.
> > > >> 3. This code is of questionable quality, contains outdated internal
> > gcc
> > > >> api
> > > >> (__sync builtins, now deprecated in favour of __atomic builtins in
> gcc
> > > and
> > > >> is not advisable to use since C++ 11). It contains a lot of autotool
> > > mess,
> > > >> while just one CMakeFile.txt is enough to build the same
> > > >> 4. This code doesn't even compile on modern gcc (gcc 9.3.0 namely)
> > > >>
> > > >> We have 2 options
> > > >> 1. If this concept is useful, we (for example I can do it) should
> > > rewrite
> > > >> native part,
> > > >> a. Use C++ 11 and header-only boost.interprocess [1]
> > > >> b. Build it regularly with CMake and incorporate build in regular TC
> > > runs
> > > >> (via maven-cmake-plugin,
> > > >> see for example my numa-allocator [2]).
> > > >> 2. If this concept and functionality is not useful, we should remove
> > it,
> > > >> may be even in 2.12
> > > >>
> > > >>
> > > >> [1] --
> > https://www.boost.org/doc/libs/1_77_0/doc/html/interprocess.html
> > > >> [2] --
> > > >>
> > > >>
> > >
> >
> https://github.com/apache/ignite/pull/9569/files#diff-77baf2378aa83911a8c3091814db3ff60b7bf328c4ab4850f707717ed96f3d92
> > > >> --
> > > >> Sincerely yours, Ivan Daschinskiy
> > > >>
> > > >
> > >
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Proxy (GridServiceProxy) for local services if required

[Ivan Daschinsky]

Yep, seems that current behaviour is not correct at all. `serviceProxy()`
should return exactly what it should -- proxy.

ср, 19 янв. 2022 г. в 10:32, Maksim Timonin :

> Hi, guys!
>
> > this is not a good idea to change the behavior of serviceProxy()
> depending on statistics
>
> I think that the patch doesn't change the behavior of `serviceProxy()`.
> This method promises a proxy and it actually returns it. The fact that
> `serviceProxy()` can return non-proxy objects is an internal Ignite
> optimization, and users should not rely on this, there is a separate method
> `service()` for that.
>
> > What are the metrics that are being affected by this?
>
> Only service metrics, that calculates duration of service execution. Check
> this ticket [1]
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12464
>
>
> On Wed, Jan 19, 2022 at 1:22 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > What are the metrics that are being affected by this?
> >
> > -Val
> >
> > On Tue, Jan 18, 2022 at 3:31 AM Вячеслав Коптилин <
> > slava.kopti...@gmail.com>
> > wrote:
> >
> > > Hello Igniters,
> > >
> > > IMHO, this is not a good idea to change the behavior of serviceProxy()
> > > depending on statistics (enabled/disabled). It seems counterintuitive
> to
> > > me.
> > > Perhaps, we need to introduce a new method that should always return a
> > > proxy to the user service.
> > >
> > > Thanks,
> > > Slava.
> > >
> > >
> > > вт, 28 дек. 2021 г. в 13:57, Pavel Pereslegin :
> > >
> > > > Hi!
> > > >
> > > > Agree with Maxim.
> > > >
> > > > It seems to me quite normal to return a proxy for a local instance in
> > > > the case when the user has explicitly enabled statistics collection
> in
> > > > the service settings. Those. by default, we do not change the
> behavior
> > > > and if the collection of metrics is not needed, a local instance will
> > > > be returned. And I also think the javadoc should be changed to
> reflect
> > > > the new behavior.
> > > >
> > > > So, I'm for 1 + 3.
> > > >
> > > > вт, 28 дек. 2021 г. в 10:51, Maksim Timonin  >:
> > > > >
> > > > > Hi!
> > > > >
> > > > > I agree that users shouldn't expect a non-proxy when invoking the
> > > > > `IgniteServices#serviceProxy()` method. I think it's up to Ignite
> to
> > > > return
> > > > > a non-proxy instance here as possible optimisation. But users have
> to
> > > use
> > > > > interfaces in any case. There is the `IgniteServices#service()`
> > method
> > > > for
> > > > > explicit return of local instances.
> > > > >
> > > > > With enabling of metrics we can break users that explicitly
> > > > > use `#serviceProxy` (proxy!), and then explicitly cast it to an
> > > > > implementation class. In this case such users will get a runtime
> > > > exception.
> > > > > I think we can write a good javadoc for
> > > > > `ServiceConfiguration#setEnableMetrics()`, it should mention that
> it
> > > > works
> > > > > only with proxy, and it doesn't collect metrics with non-proxy
> usages
> > > > with
> > > > > `IgniteService#service()`.
> > > > >
> > > > > So, I propose to proceed with two solutions - 1 and 3: fix docs for
> > > > > `#serviceProxy()` and provide detailed javadocs
> > > > > for `ServiceConfiguration#setEnableMetrics()`.
> > > > >
> > > > > If some users will enable metrics (even with such docs!) and will
> be
> > > > using
> > > > > casting proxy(!) to an implementation, then they will get a runtime
> > > > > exception. But I believe that it is an obvious failure, and it
> should
> > > be
> > > > > fixed on the user side.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Dec 27, 2021 at 10:26 PM Vladimir Steshin <
> > vlads...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi, Igniters.
> > > > > >
> > > > > >
> > > > > > I'd like to suggest modifying
> `/IgniteServices.serviceProxy(String
> > > > name,
> > > > > > Class svcItf, boolean sticky)/` so that it may return
> > > proxy
> > > > > > even for local service. Motivation: service metrics [1]. To
> measure
> > > > > > method call we need to wrap service somehow. Also, the method
> name
> > > says
> > > > > > `proxy`. For local one we return direct instance. Misleading.
> > > > > >
> > > > > >
> > > > > > Solutions:
> > > > > >
> > > > > > 1) Let’s return a proxy (`/GridServiceProxy/`) once we need.
> Let’s
> > > > > > change the javadoc to say `@return Proxy over service’. Simply
> > works.
> > > > > >
> > > > > > Pros: invocation like `/MyServiceImpl svc =
> > serviceProxy(«myservice»,
> > > > > > MyService.class)`/ would fail. Wierd usage to me. But possible.
> > > > > >
> > > > > > 2) Introduce a new method with forced-proxy flag
> > > > > > like`IgniteSerives.serviceProxy(…, boolead focedProxy)`. And add
> a
> > > > > > warning to other service-obtain methods like: «`/You enabled
> > service
> > > > > > metrics but it doesn’t work for local service instanse. Use
> > > > forced-proxy
> > > > > > serviceProxy(…, boolean forcedProxy)/` Pros: we’ve already 

Re: [VOTE] Release Apache Ignite 2.12.0 RC2

[Ivan Daschinsky]

+1 From me.

Checked Ignite.C++ on ubuntu 20.04 and windows:
1. Building and installing all components (Core, thin client and ODBC)
2. Run examples.

Checked building 64-bit and 32-bit ODBC driver installers (python + pyodbc)
Checked ODBC driver installers, shipped with ignite. (python + pyodbc)

вт, 11 янв. 2022 г. в 12:49, Anton Vinogradov :

> +1
>
> On Tue, Jan 11, 2022 at 11:35 AM Maxim Muzafarov 
> wrote:
>
> > +1
> >
> > On Tue, 11 Jan 2022 at 11:31, Nikolay Izhikov 
> wrote:
> > >
> > > +1
> > >
> > > > 11 янв. 2022 г., в 02:38, Vladimir Steshin 
> > написал(а):
> > > >
> > > > +1
> > > >
> > > > 10.01.2022 15:52, Nikita Amelchev пишет:
> > > >> Dear Community,
> > > >>
> > > >> The release candidate (2.12.0-rc2) is ready.
> > > >>
> > > >> I have uploaded a release candidate to:
> > > >> https://dist.apache.org/repos/dist/dev/ignite/2.12.0-rc2/
> > > >> https://dist.apache.org/repos/dist/dev/ignite/packages_2.12.0-rc2/
> > > >>
> > > >> The following staging can be used for testing:
> > > >>
> > https://repository.apache.org/content/repositories/orgapacheignite-1539
> > > >>
> > > >> Tag name is 2.12.0-rc2:
> > > >>
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=refs/tags/2.12.0-rc2
> > > >>
> > > >> RELEASE_NOTES:
> > > >>
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.12
> > > >>
> > > >> Complete list of resolved issues:
> > > >>
> >
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.12%27))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20ORDER%20BY%20priority
> > > >>
> > > >> DEVNOTES:
> > > >>
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.12
> > > >>
> > > >> Additional checks have been performed (available for users included
> > > >> into the release group on TeamCity).
> > > >>
> > > >> TC [Check RC: Licenses, compile, chksum]
> > > >>
> >
> https://ci2.ignite.apache.org/buildConfiguration/ignite2_Release_ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum/6266150?showRootCauses=false=true
> > > >>
> > > >> TC [2] Compare w/ Previous Release
> > > >>
> >
> https://ci2.ignite.apache.org/buildConfiguration/ignite2_Release_ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency/6266148?showRootCauses=false=true
> > > >>
> > > >> The vote is formal, see voting guidelines
> > > >> https://www.apache.org/foundation/voting.html
> > > >>
> > > >> +1 - to accept Apache Ignite 2.12.0-rc2
> > > >> 0 - don't care either way
> > > >> -1 - DO NOT accept Apache Ignite Ignite 2.12.0-rc2 (explain why)
> > > >>
> > > >> See notes on how to verify release here
> > > >> https://www.apache.org/info/verification.html
> > > >> and
> > > >>
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> > > >>
> > > >> This vote will be open until Thu Jan 13, 2022, 16:00 UTC. Please,
> > > >> write me down the thread if you need additional time to check the
> > > >> release.
> > > >>
> >
> https://www.timeanddate.com/countdown/vote?iso=20220113T16=0=VOTE+on+the+Apache+Ignite+Release+2.12.0+RC2=sanserif
> > > >>
> > >
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSSION] Shmem removal.

[Ivan Daschinsky]

Hi, Val. My plan was to file a specific ticket after discussion. If the
community agrees that this module should be removed, I will file a specific
ticket for it.

ср, 5 янв. 2022 г., 22:26 Valentin Kulichenko :

> Hi Ivan,
>
> Do we have a ticket for this?
>
> -Val
>
> On Fri, Dec 3, 2021 at 10:58 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > I think we can safely remove it.
> >
> > -Val
> >
> > On Thu, Dec 2, 2021 at 11:52 PM Ivan Daschinsky 
> > wrote:
> >
> >> Hi, igniters.
> >>
> >> Recently I've discovered one fact
> >> 1. GridShmemCommunicationClient and all shmem functionality are broken
> >> since 2.10. In master it is broken since August 2020. And nobody have
> >> noticed it, only one thread in user list.
> >> 2. We have source code for native JNI library (that is shipped in
> >> ignite-shmem.jar), but we never built it since 2015.
> >> 3. This code is of questionable quality, contains outdated internal gcc
> >> api
> >> (__sync builtins, now deprecated in favour of __atomic builtins in gcc
> and
> >> is not advisable to use since C++ 11). It contains a lot of autotool
> mess,
> >> while just one CMakeFile.txt is enough to build the same
> >> 4. This code doesn't even compile on modern gcc (gcc 9.3.0 namely)
> >>
> >> We have 2 options
> >> 1. If this concept is useful, we (for example I can do it) should
> rewrite
> >> native part,
> >> a. Use C++ 11 and header-only boost.interprocess [1]
> >> b. Build it regularly with CMake and incorporate build in regular TC
> runs
> >> (via maven-cmake-plugin,
> >> see for example my numa-allocator [2]).
> >> 2. If this concept and functionality is not useful, we should remove it,
> >> may be even in 2.12
> >>
> >>
> >> [1] -- https://www.boost.org/doc/libs/1_77_0/doc/html/interprocess.html
> >> [2] --
> >>
> >>
> https://github.com/apache/ignite/pull/9569/files#diff-77baf2378aa83911a8c3091814db3ff60b7bf328c4ab4850f707717ed96f3d92
> >> --
> >> Sincerely yours, Ivan Daschinskiy
> >>
> >
>

Re: [VOTE] Release Apache Ignite 2.12.0 RC1

[Ivan Daschinsky]

-0.5. We should update log4j2 to version 2.17.1

пт, 31 дек. 2021 г., 00:43 Nikita Amelchev :

> Dear Community,
>
> The release candidate is ready.
>
> I have uploaded a release candidate to:
> https://dist.apache.org/repos/dist/dev/ignite/2.12.0-rc1/
> https://dist.apache.org/repos/dist/dev/ignite/packages_2.12.0-rc1/
>
> The following staging can be used for testing:
> https://repository.apache.org/content/repositories/orgapacheignite-1538
>
> Tag name is 2.12.0-rc1:
>
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=refs/tags/2.12.0-rc1
>
> RELEASE_NOTES:
>
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.12
>
> Complete list of resolved issues:
>
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.12%27))%20and%20status%20in%20(%27CLOSED%27%2C%20%27RESOLVED%27)%20ORDER%20BY%20priority
>
> DEVNOTES:
>
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.12
>
> Additional checks have been performed (available for users included
> into the release group on TeamCity).
>
> TC [Check RC: Licenses, compile, chksum]
>
> https://ci2.ignite.apache.org/buildConfiguration/ignite2_Release_ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum/6253654?showRootCauses=false=true
>
> TC [2] Compare w/ Previous Release
>
> https://ci2.ignite.apache.org/buildConfiguration/ignite2_Release_ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency/6253662?showRootCauses=false
>
> The vote is formal, see voting guidelines
> https://www.apache.org/foundation/voting.html
>
> +1 - to accept Apache Ignite 2.12.0-rc1
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite Ignite 2.12.0-rc1 (explain why)
>
> See notes on how to verify release here
> https://www.apache.org/info/verification.html
> and
>
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
>
> This vote will be open until Mon Jan 10, 2022, 16:00 UTC.
> The voting time was increased due to the long NY weekend. Please,
> write me down the thread if you need additional time to check the
> release.
>
> https://www.timeanddate.com/countdown/vote?iso=20220110T16=0=VOTE+on+the+Apache+Ignite+Release+2.12.0+RC1=sanserif
>
> --
> Best wishes,
> Amelchev Nikita
>

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

[Ivan Daschinsky]

Pavel, currently they offers only free 14-day trial, unfortunately

чт, 30 дек. 2021 г. в 13:16, Pavel Tupitsyn :

> Ivan,
>
> MyGet is free within some limits.
> It was introduced to make release verification easier - no need to unzip
> nuggets into a local dir, just install them from MyGet.
>
> Nikita,
>
> No, we won't upload NuGet packages to any registry before a successful RC
> vote.
> Only then we'll push them to nuget.org (as we always do).
>
>
> On Thu, Dec 30, 2021 at 12:38 PM Ivan Daschinsky 
> wrote:
>
> > I'm sorry, but I've never understand the purpose of uploading to MyGet.
> It
> > is not free registry and it is required to pay to use it.
> >
> > чт, 30 дек. 2021 г. в 12:34, Nikita Amelchev :
> >
> > > Pavel, thank you.
> > >
> > > The "[3] Build & Upload Nuget Staging Packages" configuration also
> > > pushes packages to the MyGet.
> > > Will packages be published to some package registry?
> > >
> > > чт, 30 дек. 2021 г. в 10:15, Pavel Tupitsyn :
> > > >
> > > > NuGet packages are now prepared as part of the main config "[1]
> Release
> > > Build".
> > > > They are placed to svn/vote/apache-ignite-2.12.0-nuget.zip [1]
> > > >
> > > > I propose to remove "[3] Build & Upload Nuget Staging Packages"
> > > configuration.
> > > > NuGet packages can be downloaded from vote artifacts and verified
> > > locally by installing from a folder:
> > > > dotnet add package Apache.Ignite --source ~/Downloads/and/so/on
> > > >
> > > > Thoughts, objections?
> > > >
> > > > [1]
> > >
> >
> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6347367?buildTab=artifacts#%2Frelease-2.12.0-rc1.zip!%2Fpackages;%2Frelease-2.12.0-rc1.zip!%2Fsvn%2Fvote%2Fapache-ignite-2.12.0-nuget.zip
> > > >
> > > > On Thu, Dec 30, 2021 at 9:29 AM Pavel Tupitsyn  >
> > > wrote:
> > > >>
> > > >> Hello Nikita,
> > > >>
> > > >> I'll have a look.
> > > >>
> > > >> On Wed, Dec 29, 2021 at 6:12 PM Nikita Amelchev <
> namelc...@apache.org
> > >
> > > wrote:
> > > >>>
> > > >>> Hello. Petr, Pavel,
> > > >>>
> > > >>> It seems that the release profile to build the Nuget package was
> > > >>> broken. Could you please help with fixing it?
> > > >>>
> > > >>> [1]
> > >
> >
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/6347635
> > > >>>
> > > >>> вс, 26 дек. 2021 г. в 16:29, Nikita Amelchev  >:
> > > >>> >
> > > >>> > Igniters,
> > > >>> >
> > > >>> > There are two issues left to release 2.12:
> > > >>> >
> > > >>> > 1. The log4j dependency update in the REST module. The fix is
> > leaving
> > > >>> > only the slf4j facade for third-party libraries and allowing a
> user
> > > to
> > > >>> > configure the underlying logging framework yourself. [1]
> > > >>> >
> > > >>> > 2. Migration zookeeper-ip-finder to the extensions [2] (and then
> > > >>> > update log4j dependency) as discussed in the thread [3].
> > > >>> >
> > > >>> > Please, join the review. I have a plan to merge it at the nearest
> > > time
> > > >>> > and prepare RC.
> > > >>> >
> > > >>> > Also, I suggest including issues [4, 5] that block the snapshot
> > > restore process.
> > > >>> >
> > > >>> > [1] https://issues.apache.org/jira/browse/IGNITE-13464
> > > >>> > [2] https://issues.apache.org/jira/browse/IGNITE-16182
> > > >>> > [3]
> > https://lists.apache.org/thread/bdt9yoy3so9p26ymox3rxh45vk85toc5
> > > >>> > [4] https://issues.apache.org/jira/browse/IGNITE-16194
> > > >>> > [5] https://issues.apache.org/jira/browse/IGNITE-16177
> > > >>> >
> > > >>> > вт, 21 дек. 2021 г. в 13:34, Ivan Daschinsky <
> ivanda...@gmail.com
> > >:
> > > >>> > >
> > > >>> > > Also, zookeeper ip finder depends on go

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

[Ivan Daschinsky]

I'm sorry, but I've never understand the purpose of uploading to MyGet. It
is not free registry and it is required to pay to use it.

чт, 30 дек. 2021 г. в 12:34, Nikita Amelchev :

> Pavel, thank you.
>
> The "[3] Build & Upload Nuget Staging Packages" configuration also
> pushes packages to the MyGet.
> Will packages be published to some package registry?
>
> чт, 30 дек. 2021 г. в 10:15, Pavel Tupitsyn :
> >
> > NuGet packages are now prepared as part of the main config "[1] Release
> Build".
> > They are placed to svn/vote/apache-ignite-2.12.0-nuget.zip [1]
> >
> > I propose to remove "[3] Build & Upload Nuget Staging Packages"
> configuration.
> > NuGet packages can be downloaded from vote artifacts and verified
> locally by installing from a folder:
> > dotnet add package Apache.Ignite --source ~/Downloads/and/so/on
> >
> > Thoughts, objections?
> >
> > [1]
> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6347367?buildTab=artifacts#%2Frelease-2.12.0-rc1.zip!%2Fpackages;%2Frelease-2.12.0-rc1.zip!%2Fsvn%2Fvote%2Fapache-ignite-2.12.0-nuget.zip
> >
> > On Thu, Dec 30, 2021 at 9:29 AM Pavel Tupitsyn 
> wrote:
> >>
> >> Hello Nikita,
> >>
> >> I'll have a look.
> >>
> >> On Wed, Dec 29, 2021 at 6:12 PM Nikita Amelchev 
> wrote:
> >>>
> >>> Hello. Petr, Pavel,
> >>>
> >>> It seems that the release profile to build the Nuget package was
> >>> broken. Could you please help with fixing it?
> >>>
> >>> [1]
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/6347635
> >>>
> >>> вс, 26 дек. 2021 г. в 16:29, Nikita Amelchev :
> >>> >
> >>> > Igniters,
> >>> >
> >>> > There are two issues left to release 2.12:
> >>> >
> >>> > 1. The log4j dependency update in the REST module. The fix is leaving
> >>> > only the slf4j facade for third-party libraries and allowing a user
> to
> >>> > configure the underlying logging framework yourself. [1]
> >>> >
> >>> > 2. Migration zookeeper-ip-finder to the extensions [2] (and then
> >>> > update log4j dependency) as discussed in the thread [3].
> >>> >
> >>> > Please, join the review. I have a plan to merge it at the nearest
> time
> >>> > and prepare RC.
> >>> >
> >>> > Also, I suggest including issues [4, 5] that block the snapshot
> restore process.
> >>> >
> >>> > [1] https://issues.apache.org/jira/browse/IGNITE-13464
> >>> > [2] https://issues.apache.org/jira/browse/IGNITE-16182
> >>> > [3] https://lists.apache.org/thread/bdt9yoy3so9p26ymox3rxh45vk85toc5
> >>> > [4] https://issues.apache.org/jira/browse/IGNITE-16194
> >>> > [5] https://issues.apache.org/jira/browse/IGNITE-16177
> >>> >
> >>> > вт, 21 дек. 2021 г. в 13:34, Ivan Daschinsky :
> >>> > >
> >>> > > Also, zookeeper ip finder depends on good old log4j 1.x
> >>> > >
> >>> > > вт, 21 дек. 2021 г. в 13:32, Ivan Daschinsky  >:
> >>> > >
> >>> > > > As for me, I am +1 for removing ZookeeperIpFinder from
> ignite-zookeeper.
> >>> > > >
> >>> > > >
> >>> > > > вт, 21 дек. 2021 г. в 13:26, Nikita Amelchev <
> namelc...@apache.org>:
> >>> > > >
> >>> > > >> Folks,
> >>> > > >>
> >>> > > >> What do you think about fixing vulnerability log4j dependencies
> in
> >>> > > >> rest-http, zookeeper modules in 2.12?
> >>> > > >>
> >>> > > >> The issue is in progress and can be resolved in a few days. [1]
> >>> > > >>
> >>> > > >> I suggest including it to the scope.
> >>> > > >>
> >>> > > >> [1] https://issues.apache.org/jira/browse/IGNITE-13464
> >>> > > >>
> >>> > > >> пт, 17 дек. 2021 г. в 16:22, Вячеслав Коптилин <
> slava.kopti...@gmail.com
> >>> > > >> >:
> >>> > > >> >
> >>> > > >> > Hi Nikita,
> >>> > > >> >
> >>> >

Re: [ANNOUNCE] Welcome Vladislav Pyatkov as a new committer

[Ivan Daschinsky]

Vlad, congrats! You have definitely deserved it!

ср, 22 дек. 2021 г. в 20:40, Andrey Mashenkov :

> Congrats, Vlad!
>
> ср, 22 дек. 2021 г., 20:23 Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> > The Apache Ignite Project Management Committee (PMC) has invited
> Vladislav
> > Pyatkov to become a new committer and are happy to announce that he has
> > accepted.
> >
> > Vladislav is a veteran of the Apache Ignite project. He joined the
> > community in 2016.
> > He participated in the development of Ignite 1.x, 2.x and he is actively
> > working on a new Apache Ignite 3.0 release.
> >
> > Being a committer enables easier contribution to the project since there
> > is no need to go via the patch submission process. This should enable
> > better productivity.
> >
> > Please join me in welcoming Vlad, and congratulating him on the new role
> > in the Apache Ignite Community.
> >
> > -Val
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Move the Zookeeper IP-finder to the ignite-extensions

[Ivan Daschinsky]

Let's explain more thoroughly

Ignite module ignite-zookeeper contains 2 packages

1. org.apache.ignite.spi.discovery.tcp.ipfinder.zk;

It contains one class, TcpDiscoveryZookeeperIpFinder, that is just
implementation of TcpDiscoveryIpFinder, it uses Apache Curator
ServiceDiscovery recipe to
register and retrieve IP addresses of other nodes and use these addresses
in TcpDiscovery process. It is literally few hundred lines of code with
comments and imports.

2. org.apache.ignite.spi.discovery.zk
It contains full blown implementation of DiscoverySpi. Quite complex and a
lot of code.

These two packages have nothing common except substring "zookeeper". I
don't have any idea why they are present in one package.


ср, 22 дек. 2021 г. в 14:00, Ivan Daschinsky :

> I am +1 for removing ZookeeperIpFinder from ignite-zookeeper module. It is
> not needed here.
>
> ср, 22 дек. 2021 г. в 14:00, Ivan Daschinsky :
>
>> >> a lot of code in core code base is dedicated for enabling it.
>> It is simply not true. ZookeeperDiscovery has nothing common with
>> ZookeeperIpFinder.
>>
>> The last one is simply one class and similar to others IP finders.
>>
>> ср, 22 дек. 2021 г. в 13:25, Ilya Kasnacheev :
>>
>>> Hello!
>>>
>>> I think it might not be a good idea, since Zookeeper IP Finder is not
>>> stand-alone - a lot of code in core code base is dedicated for enabling
>>> it.
>>> This code may break unnoticed if Zookeeper IP Finder is not built/tested
>>> on
>>> every commit.
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> ср, 22 дек. 2021 г. в 12:09, Sergei Ryzhov :
>>>
>>> > Hi, igniters,
>>> >
>>> > I've created an issue [1] to move the zookeeper IP-finder to the
>>> > ignite-extensions. The motivation is the same as with migration of
>>> > cloud-based IP-finders - to remove integration dependency of the
>>> > release cycle on Ignite releases. Also, the log4j dependency with
>>> > vulnerabilities (needed for Apache Curator) will be removed from the
>>> Ignite
>>> > release.
>>> >
>>> > Any objections?
>>> >
>>> > [1] https://issues.apache.org/jira/browse/IGNITE-16182
>>> > --
>>> > Best regards,
>>> > Sergei Ryzhov
>>> >
>>>
>>
>>
>> --
>> Sincerely yours, Ivan Daschinskiy
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Move the Zookeeper IP-finder to the ignite-extensions

[Ivan Daschinsky]

I am +1 for removing ZookeeperIpFinder from ignite-zookeeper module. It is
not needed here.

ср, 22 дек. 2021 г. в 14:00, Ivan Daschinsky :

> >> a lot of code in core code base is dedicated for enabling it.
> It is simply not true. ZookeeperDiscovery has nothing common with
> ZookeeperIpFinder.
>
> The last one is simply one class and similar to others IP finders.
>
> ср, 22 дек. 2021 г. в 13:25, Ilya Kasnacheev :
>
>> Hello!
>>
>> I think it might not be a good idea, since Zookeeper IP Finder is not
>> stand-alone - a lot of code in core code base is dedicated for enabling
>> it.
>> This code may break unnoticed if Zookeeper IP Finder is not built/tested
>> on
>> every commit.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> ср, 22 дек. 2021 г. в 12:09, Sergei Ryzhov :
>>
>> > Hi, igniters,
>> >
>> > I've created an issue [1] to move the zookeeper IP-finder to the
>> > ignite-extensions. The motivation is the same as with migration of
>> > cloud-based IP-finders - to remove integration dependency of the
>> > release cycle on Ignite releases. Also, the log4j dependency with
>> > vulnerabilities (needed for Apache Curator) will be removed from the
>> Ignite
>> > release.
>> >
>> > Any objections?
>> >
>> > [1] https://issues.apache.org/jira/browse/IGNITE-16182
>> > --
>> > Best regards,
>> > Sergei Ryzhov
>> >
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Move the Zookeeper IP-finder to the ignite-extensions

[Ivan Daschinsky]

>> a lot of code in core code base is dedicated for enabling it.
It is simply not true. ZookeeperDiscovery has nothing common with
ZookeeperIpFinder.

The last one is simply one class and similar to others IP finders.

ср, 22 дек. 2021 г. в 13:25, Ilya Kasnacheev :

> Hello!
>
> I think it might not be a good idea, since Zookeeper IP Finder is not
> stand-alone - a lot of code in core code base is dedicated for enabling it.
> This code may break unnoticed if Zookeeper IP Finder is not built/tested on
> every commit.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 22 дек. 2021 г. в 12:09, Sergei Ryzhov :
>
> > Hi, igniters,
> >
> > I've created an issue [1] to move the zookeeper IP-finder to the
> > ignite-extensions. The motivation is the same as with migration of
> > cloud-based IP-finders - to remove integration dependency of the
> > release cycle on Ignite releases. Also, the log4j dependency with
> > vulnerabilities (needed for Apache Curator) will be removed from the
> Ignite
> > release.
> >
> > Any objections?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-16182
> > --
> > Best regards,
> > Sergei Ryzhov
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [RESULT] [VOTE] Release Apache Ignite 2.11.1 RC2

[Ivan Daschinsky]

nis,
> > >> >>
> > >> >> Thanks for the update.
> > >> >> I've just recently found that all releases on the download page [1]
> > >> >> have the same release date. Is it correct?
> > >> >>
> > >> >> [1] https://ignite.apache.org/download.cgi
> > >> >>
> > >> >> On Tue, 21 Dec 2021 at 14:47, Denis Magda 
> wrote:
> > >> >> >
> > >> >> > Hi Maxim,
> > >> >> >
> > >> >> > Just a reminder that since the release of the new website, we
> need
> > >> to update the download.pug [1] file in case of a release and then
> generate
> > >> the HTML version following this updated instruction. If you have any
> > >> questions, please reach out to Erlan (CC-ed).
> > >> >> >
> > >> >> > [1]
> > >>
> https://github.com/apache/ignite-website/blob/master/_src/download.pug
> > >> >> > [2]
> > >>
> https://cwiki.apache.org/confluence/display/IGNITE/Website+Development
> > >> >> >
> > >> >> > On Tue, Dec 21, 2021 at 4:36 AM Maxim Muzafarov <
> mmu...@apache.org>
> > >> wrote:
> > >> >> >>
> > >> >> >> Hello, Igniters!
> > >> >> >>
> > >> >> >>
> > >> >> >> Thanks to everyone. The vote is closed.
> > >> >> >> The emergency Apache Ignite 2.11.1 release (RC2) has been
> accepted.
> > >> >> >> I will continue on with the release.
> > >> >> >>
> > >> >> >> 5 - "+1" votes received and no "0", "-1" votes.
> > >> >> >>
> > >> >> >>
> > >> >> >> Here are the votes received:
> > >> >> >>
> > >> >> >> - Ilya Kasnacheev (binding)
> > >> >> >> - Pavel Tupitsyn (binding)
> > >> >> >> - Ivan Daschinsky
> > >> >> >> - Nikolay Izhikov (binding)
> > >> >> >> - Vyacheslav Koptilin
> > >> >> >> - Alex Plehanov (binding)
> > >> >> >> - Valentin Kulichenko (binding)
> > >> >> >>
> > >> >> >>
> > >> >> >> Here is the link to the voting thread:
> > >> >> >>
> https://lists.apache.org/thread/2pwc0fv0pczhnxbyfkdhl1m3yvh8vrpb
> > >> >> >>
> > >> >> >> Thank you!
> > >>
> > >
>


-- 
Sincerely yours, Ivan Daschinskiy

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

[Ivan Daschinsky]

Also, zookeeper ip finder depends on good old log4j 1.x

вт, 21 дек. 2021 г. в 13:32, Ivan Daschinsky :

> As for me, I am +1 for removing ZookeeperIpFinder from ignite-zookeeper.
>
>
> вт, 21 дек. 2021 г. в 13:26, Nikita Amelchev :
>
>> Folks,
>>
>> What do you think about fixing vulnerability log4j dependencies in
>> rest-http, zookeeper modules in 2.12?
>>
>> The issue is in progress and can be resolved in a few days. [1]
>>
>> I suggest including it to the scope.
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-13464
>>
>> пт, 17 дек. 2021 г. в 16:22, Вячеслав Коптилин > >:
>> >
>> > Hi Nikita,
>> >
>> > The proposed timeline looks great. Thank you!
>> >
>> > Slava.
>> >
>> > пт, 17 дек. 2021 г. в 15:32, Nikita Amelchev :
>> >
>> > > Hello, Slava.
>> > >
>> > > I am planning the following timeline:
>> > >
>> > > Voting Date: December 20, 2021
>> > > Release Date: December 27, 2021
>> > >
>> > > чт, 16 дек. 2021 г. в 11:52, Вячеслав Коптилин <
>> slava.kopti...@gmail.com>:
>> > > >
>> > > > Hello Nikita,
>> > > >
>> > > > > I have cherry-picked the issue [1] to the 2.12. It updates the
>> log4j
>> > > > version to 2.16.
>> > > > Thanks a lot!
>> > > >
>> > > > Could you please share a current timeline for the rest steps
>> related to
>> > > the
>> > > > release?
>> > > >
>> > > > Thanks,
>> > > > S.
>> > > >
>> > > > ср, 15 дек. 2021 г. в 21:45, Nikita Amelchev > >:
>> > > >
>> > > > > I have cherry-picked the issue [1] to the 2.12. It updates the
>> log4j
>> > > > > version to 2.16.
>> > > > >
>> > > > > Slava, thank you.
>> > > > >
>> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-16127
>> > > > >
>> > > > > ср, 15 дек. 2021 г. в 14:14, Вячеслав Коптилин <
>> > > slava.kopti...@gmail.com>:
>> > > > > >
>> > > > > > Hello,
>> > > > > >
>> > > > > > Nikita, it seems that we have to add the following ticket
>> > > > > > https://issues.apache.org/jira/browse/IGNITE-16127 to Apache
>> Ignite
>> > > 2.12
>> > > > > > release.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > S.
>> > > > > >
>> > > > > >
>> > > > > > вт, 14 дек. 2021 г. в 09:54, Nikita Amelchev <
>> namelc...@apache.org>:
>> > > > > >
>> > > > > > > +1 to move these auth issues to the next release. I will
>> prepare
>> > > RC at
>> > > > > > > the nearest time.
>> > > > > > >
>> > > > > > > пн, 13 дек. 2021 г. в 16:13, Pavel Tupitsyn <
>> ptupit...@apache.org
>> > > >:
>> > > > > > > >
>> > > > > > > > Agree with Nikolay, let's proceed with the release.
>> > > > > > > >
>> > > > > > > > On Mon, Dec 13, 2021 at 3:31 PM Nikolay Izhikov <
>> > > nizhi...@apache.org
>> > > > > >
>> > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > Nikita.
>> > > > > > > > >
>> > > > > > > > > I don’t think IGNITE-16068 is a release blocker.
>> > > > > > > > >
>> > > > > > > > > 1. It only happens when authentication enabled.
>> > > > > > > > > 2. There is at lease 2 workarounds:
>> > > > > > > > > a. Use the same file.encoding for all Ignite
>> nodes.
>> > > > > > > > > b. Use only latin characters in user login.
>> > > > > > > > >
>> > > > > > > > > I propose to postpone this ticket and move on with the
>> release.
>> > > > > > > > >
>> > > > > > > > > > 13 дек. 2021 г., в 15:28, Nikita Amelchev <
>> > > namelc...@a

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

[Ivan Daschinsky]

ase is blocked by one blocker issue with auth.
> > > > > > > > > >
> > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-16101
> > > > > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-16068
> > > > > > > > > >
> > > > > > > > > > чт, 9 дек. 2021 г. в 12:44, Nikita Amelchev <
> > > > > namelc...@apache.org>:
> > > > > > > > > >>
> > > > > > > > > >> Hello, Nikolay.
> > > > > > > > > >>
> > > > > > > > > >> I have cherry-picked the issue fix.
> > > > > > > > > >>
> > > > > > > > > >> Thank you.
> > > > > > > > > >>
> > > > > > > > > >> ср, 8 дек. 2021 г. в 18:47, Nikolay Izhikov <
> > > > > nizhi...@apache.org>:
> > > > > > > > > >>>
> > > > > > > > > >>> Hello.
> > > > > > > > > >>>
> > > > > > > > > >>> Let’s include [1] in 2.12 scope.
> > > > > > > > > >>>
> > > > > > > > > >>> After migrations authentication processor to security
> API
> > > we
> > > > > have
> > > > > > > an
> > > > > > > > > issue.
> > > > > > > > > >>> Persistent data region should exists on client node if
> > > > > > > authentication
> > > > > > > > > is enabled.
> > > > > > > > > >>>
> > > > > > > > > >>> It seems very annoying for the users.
> > > > > > > > > >>>
> > > > > > > > > >>> [1] https://issues.apache.org/jira/browse/IGNITE-15969
> > > > > > > > > >>>
> > > > > > > > > >>>> 2 дек. 2021 г., в 19:50, Nikita Amelchev <
> > > > > namelc...@apache.org>
> > > > > > > > > написал(а):
> > > > > > > > > >>>>
> > > > > > > > > >>>> I would like to formally announce code freeze for
> 2.12.0.
> > > Only
> > > > > > > > > >>>> blockers are accepted to be included to the scope. [1]
> > > > > > > > > >>>>
> > > > > > > > > >>>> We have one blocker issue [2] that will be fixed soon.
> > > > > > > > > >>>>
> > > > > > > > > >>>> [1]
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P3.Stabilization
> > > > > > > > > >>>> [2]
> https://issues.apache.org/jira/browse/IGNITE-15966
> > > > > > > > > >>>>
> > > > > > > > > >>>> чт, 2 дек. 2021 г. в 16:01, Nikita Amelchev <
> > > > > namelc...@apache.org
> > > > > > > >:
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> Hi, Igniters.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> The release is blocked by the auth issue [1]
> discussed
> > > > > above. The
> > > > > > > > > >>>>> patch will be prepared at the nearest time.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> I want to include the useful issue that adds the
> ability
> > > to
> > > > > > > configure
> > > > > > > > > >>>>> snapshot thread pool size if nobody minds.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> [1]
> https://issues.apache.org/jira/browse/IGNITE-15966
> > > > > > > > > >>>>> [2]
> https://issues.apache.org/jira/browse/IGNITE-16014
> > > > > > > > > >>>>>
> &

Re: [DISCUSSION] Reject join of nodes with different character encodings

[Ivan Daschinsky]

We copy values unchanged as is in bytes representation. Could you please
specify what could be done wrong?
I see only one possibility:
1. Start cluster with default encoding (This is only the windows case :)).
Set some metastorage values with non ASCII chars.
2. Stop it and restart with specifying encoding to different one.

I suppose that this is very rare case. And all that user should do -- just
erase metastore.

Another variant -- make all users to erase metastore in order to use UTF-8.


пн, 20 дек. 2021 г. в 17:59, Andrey Mashenkov :

> Ivan,
>
> I'm still not sure it is a good idea to upgrade metastorage automatically.
> Because we can't detect the correct charset the metastorage was created
> with, and
> at the same time we can't be sure the current charset is the correct one.
>
> So, is there any guarantee the metastorage is consistent even if it was
> "upgraded" successfully?
>
> As I see, we just copy metastorage keys to a temporary one in key-by-key
> manner... and then do write-back to the original one.
> Seems, if smth goes wrong, the user may get both (original and temporary)
> stores broken.
>
> On Mon, Dec 20, 2021 at 5:27 PM Ivan Daschinsky 
> wrote:
>
> > Andrey,  I believe that we already have all machinery to do migration
> safe.
> > See for
> > example
> >
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage#init
> > and
> >
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.TmpStorage.
> > This machinery was introduced for slightly different task, but we can
> reuse
> > this for the current purpose.
> >
> > пн, 20 дек. 2021 г. в 11:53, Mikhail Petrov :
> >
> > > Thank you all for your replies!
> > > I got the idea and agreed with it. Based on the results of the
> > > discussion, I have filed a ticket [1].
> > > I will try to investigate it.
> > >
> > > [1] - https://issues.apache.org/jira/browse/IGNITE-16157
> > >
> > > On 16.12.2021 20:11, Ivan Daschinsky wrote:
> > > > Andrey, agree with you, good point.
> > > >
> > > > чт, 16 дек. 2021 г., 16:27 Andrey Mashenkov <
> > andrey.mashen...@gmail.com
> > > >:
> > > >
> > > >> Guys,
> > > >>
> > > >> I like the idea with a flag, but for a different purpose.
> > > >> I think it is easy to detect the issue (using the flag) when
> > > >> metastorage was created on a new version with a fixed charset, or on
> > an
> > > >> older version with the user-defined default.
> > > >> Regarding the flag, we can choose a new strategy forcing UTF-8, or
> > > fallback
> > > >> to the old one with defaultCharset and print a warning and
> > > recommendation
> > > >> in log.
> > > >>
> > > >> Adding any compatibility stuff is absolutely error-prone because if
> > you
> > > >> fail in the middle of restoring process, you will get broken
> > metastorage
> > > >> with keys in different charsets.
> > > >> At this point, there is no way to detect broken keys anymore.
> > > >>
> > >
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSSION] Reject join of nodes with different character encodings

[Ivan Daschinsky]

Andrey,  I believe that we already have all machinery to do migration safe.
See for
example  
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage#init
and 
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.TmpStorage.
This machinery was introduced for slightly different task, but we can reuse
this for the current purpose.

пн, 20 дек. 2021 г. в 11:53, Mikhail Petrov :

> Thank you all for your replies!
> I got the idea and agreed with it. Based on the results of the
> discussion, I have filed a ticket [1].
> I will try to investigate it.
>
> [1] - https://issues.apache.org/jira/browse/IGNITE-16157
>
> On 16.12.2021 20:11, Ivan Daschinsky wrote:
> > Andrey, agree with you, good point.
> >
> > чт, 16 дек. 2021 г., 16:27 Andrey Mashenkov  >:
> >
> >> Guys,
> >>
> >> I like the idea with a flag, but for a different purpose.
> >> I think it is easy to detect the issue (using the flag) when
> >> metastorage was created on a new version with a fixed charset, or on an
> >> older version with the user-defined default.
> >> Regarding the flag, we can choose a new strategy forcing UTF-8, or
> fallback
> >> to the old one with defaultCharset and print a warning and
> recommendation
> >> in log.
> >>
> >> Adding any compatibility stuff is absolutely error-prone because if you
> >> fail in the middle of restoring process, you will get broken metastorage
> >> with keys in different charsets.
> >> At this point, there is no way to detect broken keys anymore.
> >>
>


-- 
Sincerely yours, Ivan Daschinskiy