date:20210415

[CANCEL] [VOTE] Release pyignite 0.4.0-rc0

2021-04-15 Thread Ivan Daschinsky

Dear Igniters

Unfortunately, vote should be cancelled, because there is an absence of
LICENSE and NOTICE in source package and NOTICE in binary packages.

Issue created https://issues.apache.org/jira/browse/IGNITE-14564

New vote will appear soon.


-- 
Sincerely yours, Ivan Daschinskiy

[jira] [Created] (IGNITE-14564) Add LICENSE and NOTICE file to all packages

2021-04-15 Thread Ivan Daschinsky (Jira)

Ivan Daschinsky created IGNITE-14564:


 Summary: Add LICENSE and NOTICE file to all packages
 Key: IGNITE-14564
 URL: https://issues.apache.org/jira/browse/IGNITE-14564
 Project: Ignite
  Issue Type: Task
  Components: python, thin client
Affects Versions: python-0.4.0
Reporter: Ivan Daschinsky


We should add these files to all artifacts according to Apache release policy



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

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

2021-04-15 Thread dpavlov . tasks

Hi Igniters,

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

 *New Critical Failure in master Control Utility 
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility?branch=%3Cdefault%3E
 No changes in the build

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 01:25:20 16-04-2021

[jira] [Created] (IGNITE-14563) Fix javadoc in Runner module.

2021-04-15 Thread Andrey Mashenkov (Jira)

Andrey Mashenkov created IGNITE-14563:
-

 Summary: Fix javadoc in Runner module.
 Key: IGNITE-14563
 URL: https://issues.apache.org/jira/browse/IGNITE-14563
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Mashenkov
Assignee: Ivan Bessonov
 Fix For: 3.0.0-alpha2


After IGNITE-13751 had been merged, Javadoc suite failed on TC due to lack of 
javadocs.
 Let's fix "warnings" that is related to Configuration and 
Configuration-annotation-processor modules.

Startpoint is to run javadoc goal for the apache-ignite project:
{code:java}
mvn javadoc:javadoc
{code}



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

[jira] [Created] (IGNITE-14562) Fix javadoc in Network module.

2021-04-15 Thread Andrey Mashenkov (Jira)

Andrey Mashenkov created IGNITE-14562:
-

 Summary: Fix javadoc in Network module.
 Key: IGNITE-14562
 URL: https://issues.apache.org/jira/browse/IGNITE-14562
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Mashenkov
Assignee: Ivan Bessonov
 Fix For: 3.0.0-alpha2


After IGNITE-13751 had been merged, Javadoc suite failed on TC due to lack of 
javadocs.
 Let's fix "warnings" that is related to Configuration and 
Configuration-annotation-processor modules.

Startpoint is to run javadoc goal for the apache-ignite project:
{code:java}
mvn javadoc:javadoc
{code}



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

[jira] [Created] (IGNITE-14561) Fix javadoc in Configuration module.

2021-04-15 Thread Andrey Mashenkov (Jira)

Andrey Mashenkov created IGNITE-14561:
-

 Summary: Fix javadoc in Configuration module.
 Key: IGNITE-14561
 URL: https://issues.apache.org/jira/browse/IGNITE-14561
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Mashenkov
Assignee: Kirill Gusakov
 Fix For: 3.0.0-alpha2


After IGNITE-13751 had been merged, Javadoc suite failed on TC due to lack of 
javadocs.
Let's fix "warnings" that is related to CLI modules.

Startpoint is to run javadoc goal for the apache-ignite project:
{code:java}
mvn javadoc:javadoc
{code}



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

[jira] [Created] (IGNITE-14560) Fix javadoc in CLI module.

2021-04-15 Thread Andrey Mashenkov (Jira)

Andrey Mashenkov created IGNITE-14560:
-

 Summary: Fix javadoc in CLI module.
 Key: IGNITE-14560
 URL: https://issues.apache.org/jira/browse/IGNITE-14560
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Mashenkov
Assignee: Andrey Mashenkov
 Fix For: 3.0.0-alpha2


After IGNITE-13751 had been merged, Javadoc suite failed on TC due to lack of 
javadocs.

Let's fix "warnings" that is related to Table,  Schema modules and packages in 
API module related to Table and Schema.



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

Re: [VOTE][EXTENSION] Release Apache Ignite performance-statistics-ext, spring-data-all-ext and spring-tx-ext extensions 1.0.0 RC1

2021-04-15 Thread Nikita Amelchev

According to ASF release policy [1] non-PMC committers can sign artifacts:

> all artifacts placed in their directory must be signed by a committer, 
> preferably by a PMC member.

[1] https://www.apache.org/legal/release-policy.html

чт, 15 апр. 2021 г. в 23:05, Dmitriy Pavlov :
>
> My best guess that since PMCs have a binding vote in voting in release, a
> PMC member should sign binaries as well. And I suppose that in the past
> only PMC members were signing the release.
>
> Meanwhile, https://infra.apache.org/release-signing.html does not contain
> any mention of PMC role and only committers are mentioned there. It
> might be not an answer, since a lot of projects have PMC=Committer and just
> one election.
>
> Sincerely,
> Dmitriy Pavlov
>
> чт, 15 апр. 2021 г. в 22:05, Ivan Daschinsky :
>
> > I'm sorry, but is it OK, that artifacts are signed with signature of
> > non-PMC?
> >
> > чт, 15 апр. 2021 г. в 19:26, Nikita Amelchev :
> >
> > > Dear Ignite Community,
> > >
> > > I have uploaded a release candidate of the following extension modules:
> > >
> > > performance-statistics-ext
> > > spring-data-ext
> > > spring-data-2.0-ext
> > > spring-data-2.2-ext
> > > spring-data-commons
> > > spring-tx-ext
> > >
> > > The release candidate of the performance-statistics-ext extension:
> > >
> > >
> > https://dist.apache.org/repos/dist/dev/ignite/ignite-performance-statistics-ext/1.0.0-rc1/
> > >
> > > The following staging can be used for testing:
> > > https://repository.apache.org/content/repositories/orgapacheignite-1509
> > >
> > > Tags were created:
> > >
> > > ignite-performance-statistics-ext-1.0.0-rc1
> > >
> > >
> > https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=b992d9758278c38e93b375b08e4052954744a436
> > >
> > > ignite-spring-data-ext-1.0.0-rc1
> > > ignite-spring-data-2.2-ext-1.0.0-rc1
> > > ignite-spring-data-2.0-ext-1.0.0-rc1
> > > ignite-spring-data-commons-1.0.0-rc1
> > > ignite-spring-data-all-ext-1.0.0-rc1
> > >
> > >
> > https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=277ca95f6472d8bd46d906e70ba1a312d36dadb0
> > >
> > > ignite-spring-tx-ext-1.0.0-rc1
> > >
> > >
> > https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=55a3ae9e011ba48796847a33481842f154f0febb
> > >
> > > RELEASE NOTES:
> > >
> > >
> > https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=blob;f=RELEASE_NOTES.txt;h=22f8d665c194ba2dfa6167354d97ad53d5ef206f;hb=c8de80ee14d1fb76d6cbb0b18513bb70b499c3cb
> > >
> > > DOCUMENTATION:
> > > Documentation of listed extensions was updated in the following issues:
> > >
> > >
> > https://issues.apache.org/jira/issues/?filter=-1=key%20in%20(IGNITE-14417%2CIGNITE-14398%2CIGNITE-14397%2CIGNITE-14493)
> > >
> > > The vote is formal, see voting guidelines
> > > https://www.apache.org/foundation/voting.html
> > >
> > > +1 - to accept all the Apache Ignite performance-statistics-ext,
> > > spring-data-all-ext and spring-tx-ext extensions 1.0.0-rc1 listed in
> > > the thread
> > > 0 - don't care either way
> > > -1 - DO NOT accept either of the Apache Ignite
> > > performance-statistics-ext, spring-data-all-ext and spring-tx-ext
> > > extensions 1.0.0-rc1 (explain why)
> > >
> > > The vote will hold for 72 hours and will end on April 18 2021 17:00 UTC
> > >
> > >
> > https://www.timeanddate.com/countdown/generic?iso=20210418T17=1440=cursive
> > >
> > > --
> > > Best wishes,
> > > Amelchev Nikita
> > >
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >



-- 
Best wishes,
Amelchev Nikita

Re: [VOTE][EXTENSION] Release Apache Ignite performance-statistics-ext, spring-data-all-ext and spring-tx-ext extensions 1.0.0 RC1

2021-04-15 Thread Dmitriy Pavlov

My best guess that since PMCs have a binding vote in voting in release, a
PMC member should sign binaries as well. And I suppose that in the past
only PMC members were signing the release.

Meanwhile, https://infra.apache.org/release-signing.html does not contain
any mention of PMC role and only committers are mentioned there. It
might be not an answer, since a lot of projects have PMC=Committer and just
one election.

Sincerely,
Dmitriy Pavlov

чт, 15 апр. 2021 г. в 22:05, Ivan Daschinsky :

> I'm sorry, but is it OK, that artifacts are signed with signature of
> non-PMC?
>
> чт, 15 апр. 2021 г. в 19:26, Nikita Amelchev :
>
> > Dear Ignite Community,
> >
> > I have uploaded a release candidate of the following extension modules:
> >
> > performance-statistics-ext
> > spring-data-ext
> > spring-data-2.0-ext
> > spring-data-2.2-ext
> > spring-data-commons
> > spring-tx-ext
> >
> > The release candidate of the performance-statistics-ext extension:
> >
> >
> https://dist.apache.org/repos/dist/dev/ignite/ignite-performance-statistics-ext/1.0.0-rc1/
> >
> > The following staging can be used for testing:
> > https://repository.apache.org/content/repositories/orgapacheignite-1509
> >
> > Tags were created:
> >
> > ignite-performance-statistics-ext-1.0.0-rc1
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=b992d9758278c38e93b375b08e4052954744a436
> >
> > ignite-spring-data-ext-1.0.0-rc1
> > ignite-spring-data-2.2-ext-1.0.0-rc1
> > ignite-spring-data-2.0-ext-1.0.0-rc1
> > ignite-spring-data-commons-1.0.0-rc1
> > ignite-spring-data-all-ext-1.0.0-rc1
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=277ca95f6472d8bd46d906e70ba1a312d36dadb0
> >
> > ignite-spring-tx-ext-1.0.0-rc1
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=55a3ae9e011ba48796847a33481842f154f0febb
> >
> > RELEASE NOTES:
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=blob;f=RELEASE_NOTES.txt;h=22f8d665c194ba2dfa6167354d97ad53d5ef206f;hb=c8de80ee14d1fb76d6cbb0b18513bb70b499c3cb
> >
> > DOCUMENTATION:
> > Documentation of listed extensions was updated in the following issues:
> >
> >
> https://issues.apache.org/jira/issues/?filter=-1=key%20in%20(IGNITE-14417%2CIGNITE-14398%2CIGNITE-14397%2CIGNITE-14493)
> >
> > The vote is formal, see voting guidelines
> > https://www.apache.org/foundation/voting.html
> >
> > +1 - to accept all the Apache Ignite performance-statistics-ext,
> > spring-data-all-ext and spring-tx-ext extensions 1.0.0-rc1 listed in
> > the thread
> > 0 - don't care either way
> > -1 - DO NOT accept either of the Apache Ignite
> > performance-statistics-ext, spring-data-all-ext and spring-tx-ext
> > extensions 1.0.0-rc1 (explain why)
> >
> > The vote will hold for 72 hours and will end on April 18 2021 17:00 UTC
> >
> >
> https://www.timeanddate.com/countdown/generic?iso=20210418T17=1440=cursive
> >
> > --
> > Best wishes,
> > Amelchev Nikita
> >
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>

[jira] [Created] (IGNITE-14559) Fix javadoc in schema and table modules

2021-04-15 Thread Andrey Mashenkov (Jira)

Andrey Mashenkov created IGNITE-14559:
-

 Summary: Fix javadoc in schema and table modules
 Key: IGNITE-14559
 URL: https://issues.apache.org/jira/browse/IGNITE-14559
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Mashenkov
Assignee: Andrey Mashenkov


After IGNITE-13751 had been merged, Javadoc suite failed on TC due to lack of 
javadocs.

Let's fix "warnings" that is related to Table,  Schema modules and packages in 
API module related to Table and Schema.



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

Re: [VOTE][EXTENSION] Release Apache Ignite performance-statistics-ext, spring-data-all-ext and spring-tx-ext extensions 1.0.0 RC1

2021-04-15 Thread Ivan Daschinsky

I'm sorry, but is it OK, that artifacts are signed with signature of
non-PMC?

чт, 15 апр. 2021 г. в 19:26, Nikita Amelchev :

> Dear Ignite Community,
>
> I have uploaded a release candidate of the following extension modules:
>
> performance-statistics-ext
> spring-data-ext
> spring-data-2.0-ext
> spring-data-2.2-ext
> spring-data-commons
> spring-tx-ext
>
> The release candidate of the performance-statistics-ext extension:
>
> https://dist.apache.org/repos/dist/dev/ignite/ignite-performance-statistics-ext/1.0.0-rc1/
>
> The following staging can be used for testing:
> https://repository.apache.org/content/repositories/orgapacheignite-1509
>
> Tags were created:
>
> ignite-performance-statistics-ext-1.0.0-rc1
>
> https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=b992d9758278c38e93b375b08e4052954744a436
>
> ignite-spring-data-ext-1.0.0-rc1
> ignite-spring-data-2.2-ext-1.0.0-rc1
> ignite-spring-data-2.0-ext-1.0.0-rc1
> ignite-spring-data-commons-1.0.0-rc1
> ignite-spring-data-all-ext-1.0.0-rc1
>
> https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=277ca95f6472d8bd46d906e70ba1a312d36dadb0
>
> ignite-spring-tx-ext-1.0.0-rc1
>
> https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=55a3ae9e011ba48796847a33481842f154f0febb
>
> RELEASE NOTES:
>
> https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=blob;f=RELEASE_NOTES.txt;h=22f8d665c194ba2dfa6167354d97ad53d5ef206f;hb=c8de80ee14d1fb76d6cbb0b18513bb70b499c3cb
>
> DOCUMENTATION:
> Documentation of listed extensions was updated in the following issues:
>
> https://issues.apache.org/jira/issues/?filter=-1=key%20in%20(IGNITE-14417%2CIGNITE-14398%2CIGNITE-14397%2CIGNITE-14493)
>
> The vote is formal, see voting guidelines
> https://www.apache.org/foundation/voting.html
>
> +1 - to accept all the Apache Ignite performance-statistics-ext,
> spring-data-all-ext and spring-tx-ext extensions 1.0.0-rc1 listed in
> the thread
> 0 - don't care either way
> -1 - DO NOT accept either of the Apache Ignite
> performance-statistics-ext, spring-data-all-ext and spring-tx-ext
> extensions 1.0.0-rc1 (explain why)
>
> The vote will hold for 72 hours and will end on April 18 2021 17:00 UTC
>
> https://www.timeanddate.com/countdown/generic?iso=20210418T17=1440=cursive
>
> --
> Best wishes,
> Amelchev Nikita
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Re[2]: [DISCUSSION] MaxLineLength checkstyle rule

2021-04-15 Thread Maxim Muzafarov

Folks,

I've briefly checked the total amount of the max length violations:

120 line length - 5540 violations
130 line length - 1891 violations
140 line length - 895 violations
150 line length - 478 violations


I think the 140 max line length might be the best option for us.

On Thu, 15 Apr 2021 at 14:51, Ivan Daschinsky  wrote:
>
> But super long lines are a real problem while merging. It is super
> inconvenient.
> 120 chars is a good compromise.
>
> чт, 15 апр. 2021 г. в 14:39, Zhenya Stanilovsky  >:
>
> >
> > Python is not so verbose as java )
> > +1 for 140
> >
> > >Hi!
> > >Personally, I suppose that 120 chars per line is OK. Moreover, many
> > >codestyles suggests less chars per line.
> > >For example PEP8 recommends 80 (but we use 120 in pyignite and flake8
> > >codestyle checks it). Google java codestyle insists on 100.
> > >
> > >More than 120 chars is too long as for me and is not convenient for 3-way
> > >merges.
> > >
> > >чт, 15 апр. 2021 г. в 12:28, Nikolay Izhikov < nizhi...@apache.org >:
> > >
> > >> Hello, Ilya.
> > >>
> > >> Thanks for the feedback.
> > >>
> > >> 140 characters is fine for me.
> > >>
> > >> > 15 апр. 2021 г., в 12:25, Ilya Kasnacheev < ilya.kasnach...@gmail.com
> > >
> > >> написал(а):
> > >> >
> > >> > Hello!
> > >> >
> > >> > Please find attached the distribution of line lengths in the project,
> > in
> > >> the form of (count, line length).
> > >> >
> > >> > I think that we can enforce a hard limit of 140 chars per line. I
> > think
> > >> that having longer lines is excessive and does not benefit readability.
> > >> >
> > >> > Having a limit of 150 or 180 does not give us much since there's still
> > >> a long tail which has to be fixed.
> > >> >
> > >> > Regards,
> > >> > --
> > >> > Ilya Kasnacheev
> > >> >
> > >> >
> > >> > чт, 15 апр. 2021 г. в 11:30, Nikolay Izhikov < nizhi...@apache.org >:
> > >> > Hello, Igniters.
> > >> >
> > >> > Right now, we have a code style rule [1] - the line should fit in 120
> > >> characters.
> > >> > But, this rule violated in many and many places through code.
> > >> > I have a plan to add a check style rule to force maximum line length.
> > >> >
> > >> > For me, personally, 120 characters a bit old-fashioned restriction.
> > >> > Should we increase the maximum line length to 150 or even 180
> > characters?
> > >> >
> > >> > [1]
> > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > >> > 
> > >>
> > >>
> > >--
> > >Sincerely yours, Ivan Daschinskiy
> >
> >
> >
> >
>
>
>
> --
> Sincerely yours, Ivan Daschinskiy

Re: IEP-70: Async Continuation Executor

2021-04-15 Thread Pavel Tupitsyn

I'll keep the common pool then, thank you.
Public pool is the "work-horse of the Compute Grid" [1], so it does not
seem to fit here at all.

[1]
https://ignite.apache.org/docs/latest/perf-and-troubleshooting/thread-pools-tuning#public-pool

On Thu, Apr 15, 2021 at 2:18 PM Stanislav Lukyanov 
wrote:

> Giving this another thought - I'm kinda torn on this myself now, as I like
> you argument that a chain of multiple (GG and not GG) continuations should
> execute in the same pool.
> This would probably be easier to understand for a beginning or
> intermediate Ignite user, which is the majority.
> Anyway, I'll leave to you to decide.
>
> > On 15 Apr 2021, at 11:02, Stanislav Lukyanov 
> wrote:
> >
> > Hi Pavel,
> >
> > I'd prefer public pool.
> >
> > Thanks,
> > Stan
> >
> >> On 12 Apr 2021, at 20:17, Pavel Tupitsyn  wrote:
> >>
> >> Stan,
> >>
> >> Sorry for the late reply (had a vacation).
> >>
> >>> In my ideal world, the users don't configure thread pools, they just
> have
> >> safe default behavior (async execution)
> >>> and a way to make it fast for one particular function (with annotation
> or
> >> anything else).
> >>
> >> I've
> >> added
> testRemoteOperationListenerExecutesOnStripedPoolWhenCustomExecutorIsProvided
> >> to demonstrate this use case.
> >>
> >>
> >>> I'm OK to proceed with the approach you're suggesting if I haven't
> >> convinced you by now
> >>
> >> Are you OK to merge the changes as is (ForkJoinPool#commonPool as the
> >> default executor),
> >> or do we change it to Ignite public pool?
> >>
> >> On Mon, Mar 29, 2021 at 11:09 PM Stanislav Lukyanov <
> stanlukya...@gmail.com>
> >> wrote:
> >>
> >>> But what if I need to have exactly one callback synchronous, and all
> other
> >>> can be asynchronous?
> >>>
> >>> I would separate two cases: an existing user who wants their old
> behavior
> >>> back, and a new user that wants to fine tune their app.
> >>> The existing user needs a global "make it all synchronous" switch.
> >>> The new user should only enable the fast-but-dangerous behavior
> locally,
> >>> exactly where they need it.
> >>>
> >>> In my ideal world, the users don't configure thread pools, they just
> have
> >>> safe default behavior (async execution)
> >>> and a way to make it fast for one particular function (with annotation
> or
> >>> anything else).
> >>> Also, this should work in a similar way for different APIs - so I'm
> trying
> >>> to lay some basis to rework all of these continuous queries and event
> >>> listeners,
> >>> even though they're explicitly mentioned as out of scope for IEP-70.
> >>>
> >>> At the same time, I understand that any change we make now will have
> pros
> >>> and cons, and we can't make it perfect because of compatibility
> reasons.
> >>> I'm OK to proceed with the approach you're suggesting if I haven't
> >>> convinced you by now :)
> >>>
> >>> Thanks,
> >>> Stan
> >>>
>  On 29 Mar 2021, at 22:47, Pavel Tupitsyn 
> wrote:
> 
>  Stan,
> 
>  Unfortunately, annotations have a few drawbacks:
>  * Can't configure it globally ("I already use sync callbacks, give me
> >>> back
>  the old behavior in one line")
>  * Can't configure in Spring
>  * Useless in C++ & .NET
>  * You can already specify executor in IgniteFuture#listenAsync, so
> there
>  seems to be no added value
> 
> > the only value we really expect the user to set in that property is
>  Runnable::run
>  Not really - there are lots of available options [1].
>  Some apps may already have one or more thread pools that can be used
> for
>  continuations.
> 
> > you can't specify Runnable::run in a Spring XML
>  Good point, but creating a class for that is trivial.
>  We can ship a ready-made class and mention it in the docs for
> simplicity.
> 
> 
>  Globally configurable Executor fits nicely with
>  existing IgniteFuture#listenAsync,
>  not sure why you dislike it.
> 
> 
>  [1]
> 
> >>>
> https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html
> 
>  On Mon, Mar 29, 2021 at 10:23 PM Stanislav Lukyanov <
> >>> stanlukya...@gmail.com>
>  wrote:
> 
> > Thought about this some more.
> >
> > I agree that we need to be able to switch to synchronous listeners
> when
> > it's critical for performance.
> > However, I don't like to introduce an Executor property for that. In
> >>> fact,
> > the only value
> > we really expect the user to set in that property is Runnable::run -
> >>> seems
> > to be an overkill to have accept an Executor for that.
> > Furthermore, you can't specify Runnable::run in a Spring XML, can
> you?
> >
> > I'm thinking that maybe we should go the annotation route here.
> > Let's introduce an annotation @IgniteSyncCallback. It's the same as
> > @IgniteAsyncCallback but reverse :)
> > If a listener is annotated like that then we execute it in the same
> >

[VOTE][EXTENSION] Release pyignite 0.4.0-rc0

2021-04-15 Thread Ivan Daschinsky

Dear Igniters!

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

If you follow the link above, you will find source package (*.tar.gz and
*.zip)
and binary packages (wheels) for windows (x86, amd64) and linux (x86 and
x86_64)
for pythons 36, 37, 38, 39. Also, there are sha512 and gpg signatures.

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.4.0-cp38-cp38-manylinux1_x86_64.whl

You can build and install package from source using this command:
>> pip install pyignite-0.4.0.tar.gz

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.4.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.4.0.rc0/examples.html

Release notes:
https://gitbox.apache.org/repos/asf?p=ignite-python-thin-client.git;a=blob;f=RELEASE_NOTES.txt;h=9fee8ead3f70718767f6e11f93d1c7e77c61657b;hb=466b54527e6e42bc585c594d840a959d0b8626ef

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

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

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

The vote will end at April, 19 18:34 UTC.

[jira] [Created] (IGNITE-14558) Add information about javadoc validation and generation commands to DEVNOTES.md

2021-04-15 Thread Andrey N. Gura (Jira)

Andrey N. Gura created IGNITE-14558:
---

 Summary: Add information about javadoc validation and generation 
commands to DEVNOTES.md 
 Key: IGNITE-14558
 URL: https://issues.apache.org/jira/browse/IGNITE-14558
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey N. Gura
Assignee: Andrey Mashenkov
 Fix For: 3.0.0-alpha2


https://issues.apache.org/jira/browse/IGNITE-13751 is implemented and merged 
but DEVNOTES.md is not updated.

Information about javadoc validation and generation commands should be added to 
DEVNOTES.md.



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

Re: welcome message

2021-04-15 Thread Ilya Kasnacheev

Hello!

I have added you to the contributor role, now you can assign issues to
yourself.

Please familiarize with
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Regards,
-- 
Ilya Kasnacheev


чт, 15 апр. 2021 г. в 18:30, Eduard Rakhmankulov :

> Hello Ignite Community!
>
> My name is Eduard. I want to contribute to Apache Ignite, my JIRA username
> *erixon*.
>
> Thanks!
>
> --
> Best regards, Eduard.
>

[IGNITE-7641] Add CacheEntry#ttl method

2021-04-15 Thread Stephen Darlington

Hi all,

I created a pull request that creates new method on IgniteCache that returns 
the current TTL of a record. I’m not entirely clear who I should tag for a 
review, so I’m posting here.

> https://issues.apache.org/jira/browse/IGNITE-7641 
> 
I 
https://github.com/apache/ignite/pull/8780

I decided to implement as a method on IgniteCache rather than CacheEntry to 
avoid having to copy the whole record over the network just to figure out the 
TTL. Unless I missed something, it didn’t appear to be as simple to implement 
as the comments in the ticket would make you think!

Thoughts?

Regards,
Stephen

[VOTE][EXTENSION] Release Apache Ignite performance-statistics-ext, spring-data-all-ext and spring-tx-ext extensions 1.0.0 RC1

2021-04-15 Thread Nikita Amelchev

Dear Ignite Community,

I have uploaded a release candidate of the following extension modules:

performance-statistics-ext
spring-data-ext
spring-data-2.0-ext
spring-data-2.2-ext
spring-data-commons
spring-tx-ext

The release candidate of the performance-statistics-ext extension:
https://dist.apache.org/repos/dist/dev/ignite/ignite-performance-statistics-ext/1.0.0-rc1/

The following staging can be used for testing:
https://repository.apache.org/content/repositories/orgapacheignite-1509

Tags were created:

ignite-performance-statistics-ext-1.0.0-rc1
https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=b992d9758278c38e93b375b08e4052954744a436

ignite-spring-data-ext-1.0.0-rc1
ignite-spring-data-2.2-ext-1.0.0-rc1
ignite-spring-data-2.0-ext-1.0.0-rc1
ignite-spring-data-commons-1.0.0-rc1
ignite-spring-data-all-ext-1.0.0-rc1
https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=277ca95f6472d8bd46d906e70ba1a312d36dadb0

ignite-spring-tx-ext-1.0.0-rc1
https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=commit;h=55a3ae9e011ba48796847a33481842f154f0febb

RELEASE NOTES:
https://gitbox.apache.org/repos/asf?p=ignite-extensions.git;a=blob;f=RELEASE_NOTES.txt;h=22f8d665c194ba2dfa6167354d97ad53d5ef206f;hb=c8de80ee14d1fb76d6cbb0b18513bb70b499c3cb

DOCUMENTATION:
Documentation of listed extensions was updated in the following issues:
https://issues.apache.org/jira/issues/?filter=-1=key%20in%20(IGNITE-14417%2CIGNITE-14398%2CIGNITE-14397%2CIGNITE-14493)

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

+1 - to accept all the Apache Ignite performance-statistics-ext,
spring-data-all-ext and spring-tx-ext extensions 1.0.0-rc1 listed in
the thread
0 - don't care either way
-1 - DO NOT accept either of the Apache Ignite
performance-statistics-ext, spring-data-all-ext and spring-tx-ext
extensions 1.0.0-rc1 (explain why)

The vote will hold for 72 hours and will end on April 18 2021 17:00 UTC
https://www.timeanddate.com/countdown/generic?iso=20210418T17=1440=cursive

-- 
Best wishes,
Amelchev Nikita

Re: [ANNOUNCE] Welcome Ivan Daschinsky as a new committer

2021-04-15 Thread Dmitriy Pavlov

Congrats, Ivan!

вт, 13 апр. 2021 г. в 20:02, Ivan Daschinsky :

> Guys, many thanks to all of you!
>
> вт, 13 апр. 2021 г. в 13:19, Alex Plehanov :
>
> > Ivan, congratulations!
> >
> >
> > вт, 13 апр. 2021 г. в 13:02, Andrey Mashenkov <
> andrey.mashen...@gmail.com
> > >:
> >
> > > Ivan, congrats!
> > >
> > > On Tue, Apr 13, 2021 at 11:42 AM Alexei Scherbakov <
> > > alexey.scherbak...@gmail.com> wrote:
> > >
> > > > Ivan, great work.
> > > >
> > > > вт, 13 апр. 2021 г. в 10:53, Ivan Pavlukhin :
> > > >
> > > > > Ivan, congrats!
> > > > >
> > > > > 2021-04-13 9:41 GMT+03:00, Nikolay Izhikov :
> > > > > > Congrats! Well deserved.
> > > > > >
> > > > > >> 13 апр. 2021 г., в 09:34, Zhenya Stanilovsky
> > > >  > > > > >
> > > > > >> написал(а):
> > > > > >>
> > > > > >>
> > > > > >> Big deal ! Ivan, ignite it !)
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>> The Project Management Committee (PMC) for Apache Ignite has
> > > invited
> > > > > >>> Ivan Daschinsky to become a committer and we are pleased to
> > > announce
> > > > > >>> that
> > > > > >>> he has accepted.
> > > > > >>>
> > > > > >>> Ivan made a lot of contributions to Apache Ignite.
> > > > > >>> He helped a lot to improve our Python Thin Client fixing a lot
> of
> > > > > >>> different
> > > > > >>> bugs and contributing major feature such as asyncio support and
> > > > > >>> C-extension
> > > > > >>> which improved performance significantly for many cases. Thanks
> > to
> > > > Ivan
> > > > > >>> Python
> > > > > >>> Thin client has become much more stable and production-ready.
> He
> > > also
> > > > > >>> introduced the CMake building system for Ignite C++, and has
> > made a
> > > > > >>> number
> > > > > >>> of
> > > > > >>> other important improvements. Besides the code contributions,
> > Ivan
> > > is
> > > > > >>> also
> > > > > >>> an
> > > > > >>> active community member.
> > > > > >>>
> > > > > >>> 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 Ivan, and congratulating him on the
> > new
> > > > > role
> > > > > >>> in
> > > > > >>> the Apache Ignite Community.
> > > > > >>>
> > > > > >>> Best Regards,
> > > > > >>> Igor
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Best regards,
> > > > Alexei Scherbakov
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrey V. Mashenkov
> > >
> >
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>

welcome message

2021-04-15 Thread Eduard Rakhmankulov

Hello Ignite Community!

My name is Eduard. I want to contribute to Apache Ignite, my JIRA username
*erixon*.

Thanks!

-- 
Best regards, Eduard.

Re: [DISCUSSION] Error handling in Ignite 3

2021-04-15 Thread Andrey Mashenkov

Hi Alexey,
I like the idea.

1.

>   TBL-0001 is a *string representation* of the error. It is built from 2
> byte scope id (mapped to name TBL) and 2 byte number (0001). Both
> internally packed in int. No any kind of parsing will be necessary to read
> scope/category.

I think Alexey mean if it will be possible to make smth like that

catch (IgniteException e) {
if (e.getScope() == "TBL" && e.getCode() == 1234)
continue; // E.g. retry my TX
}

It looks useful to me.

2. How you see a cross-module exception throwing?
Assume, user call -> module A, which recursively call -> module B, which
fails.
So, module A component calls a module B component and got an Exception with
"B-1234" exception.
Module A do not expect any exception here and doesn't take care of "B-xxx"
error codes, but only "A-.
Should it rethrow exception with "A-unknown" (maybe "UNK-0001") code
or reuse "B-" code with the own message, pointing original exception as
a cause for both cases?

The first approach may looks confusing, while the second one produces too
many "UNK-" codes.
What code should get the user in that case?





On Thu, Apr 15, 2021 at 5:36 PM Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:

> чт, 15 апр. 2021 г. в 14:26, Ilya Kasnacheev :
>
> > Hello!
> >
> > > All public methods throw only unchecked
> > org.apache.ignite.lang.IgniteException containing aforementioned fields.
> > > Each public method must have a section in the javadoc with a list of
> all
> > possible error codes for this method.
> >
> > I don't think this is feasible at all.
> > Imagine javadoc for cache.get() method featuring three pages of possible
> > error codes thrown by this method.
> >
>
> Of course there is no need to write 3 pages of error codes, this makes no
> sense.
> I think we can use error ranges here, or, probably, document most important
> error scenarios.
> The point here is to try to document errors as much as possible.
>
>
> > Also, updated every two weeks to account for changes in
> > underlying mechanisms.
> >
> > There is still a confusion between "error code for any error in logs" and
> > "error code for any pair of method & exception". Which one are we
> > discussing really?
> >
> > This is impossible to track or test, but is susceptible for common
> > error-hiding antipattern where all exceptions are caught in cache.get()
> and
> > discarded, and instead a brand new CH-0001 "error in cache.get()" is
> thrown
> > to the user.
> >
> > Which is certainly not something that anybody wants.
> >
>
> Certainly not. We are talking here about root cause - what is exactly the
> reason for method call failure.
>
>
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 15 апр. 2021 г. в 13:03, Vladislav Pyatkov :
> >
> > > Hi Alexei,
> > >
> > > > Each public method *must *have a section in the javadoc with a list
> of
> > > all possible error codes for this method.
> > >
> > > I consider it is redundant, because any public exception can be thrown
> > from
> > > public API.
> > > If it not happens today, it may change tomorrow: one will be removed,
> > > another one will be added.
> > >
> > > >Nested exceptions are not forbidden to use. They can provide
> additional
> > > details on the error for debug purposes
> > >
> > > I see another issue, which is in the Ignite 2.x, but not attend here.
> We
> > > can have a deep nested exception and use it for handling.
> > > In the result, all time when we are handling an exception we use
> > > pattern like this:
> > > try{
> > > ...
> > > }
> > > catch (Exception e) {
> > > if (X.hasCause(e, TimeoutException.class))
> > > throw e;
> > >
> > > if (X.hasCause(e, ConnectException.class, EOFException.class))
> > > continue;
> > >
> > > if (X.hasCause(e, InterruptedException.class))
> > > return false;
> > > }
> > >
> > > If we have a pant to make only one exception to the client side, we can
> > > also do it for an internal exception.
> > >
> > > On Wed, Apr 14, 2021 at 11:42 AM Alexei Scherbakov <
> > > alexey.scherbak...@gmail.com> wrote:
> > >
> > > > Alexey,
> > > >
> > > > ср, 14 апр. 2021 г. в 01:52, Alexey Kukushkin <
> > kukushkinale...@gmail.com
> > > >:
> > > >
> > > > > Just some points looking questionable to me, although I realize the
> > > error
> > > > > handling style may be very opinionated:
> > > > >
> > > > >- Would it make sense splitting the proposed composite error
> code
> > > > >(TBL-0001) into separate numeric code (0001) and scope/category
> > > > ("TBL")
> > > > > to
> > > > >avoid parsing the code when an error handler needs to analyze
> only
> > > the
> > > > >category or the code?
> > > > >
> > > >
> > > >   TBL-0001 is a *string representation* of the error. It is built
> from
> > 2
> > > > byte scope id (mapped to name TBL) and 2 byte number (0001). Both
> > > > internally packed in int. No any kind of parsing will be necessary to
> > > read
> > > > scope/category.
> > > >
> > > >
> > > > >

[jira] [Created] (IGNITE-14557) Imrove row layout.

2021-04-15 Thread Andrey Mashenkov (Jira)

Andrey Mashenkov created IGNITE-14557:
-

 Summary: Imrove row layout.
 Key: IGNITE-14557
 URL: https://issues.apache.org/jira/browse/IGNITE-14557
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey Mashenkov


h3. Motivation.

When one try to read a column value from a row, the very first check will be a 
null-check.
As Null-Table resides right after an Offset-Table, the we need 2 jumps to for 
the null-check.
h3. Description.

Assuming, Null-Table reserves a bit for each columns even if the columns is not 
Nullable,
Null-table has constant size (within same version of schema) and we no need 
extra bytes to persist it's length into the tuple.
 * Null-checks will not require extra read for Offset-Table size and extra jump.
 * Offset-Table will not need extra read/jump to reach as Null-Table size is 
constant.

Let's just swap these tables in layout and fix docs README.md and IEP.

 



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

[jira] [Created] (IGNITE-14556) Add Tuple validation.

2021-04-15 Thread Andrey Mashenkov (Jira)

Andrey Mashenkov created IGNITE-14556:
-

 Summary: Add Tuple validation.
 Key: IGNITE-14556
 URL: https://issues.apache.org/jira/browse/IGNITE-14556
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey Mashenkov


At a point of Table public method call by a user, we need to validate user 
input.

We can add this logic to check if value fields match the current schema version 
(no new fields).
 * For LIVE-Schema. If Tuple has one or more additional columns, then we should 
try to register a new schema first, then proceed with the user operation.
 * For STRICT-Schema.  If Tuple has one or more additional columns, then we 
should fail the user operation.
 * For KeyValueView, we should validate key Tuple as well, and fail if there 
are unknown columns. Because a key column span is immutable. The only exception 
may be if a user creates a schemaless table, then a schema of the 1-st version 
should be registered instantly.

Assumed, any column type mismatch or missed Non-Nullable columns will be caught 
and processed by RowAssembler.

 

It is possible to add the validation into a TupleBuilder and then just check 
the Tuple instance class (should be a builder). 
For any Tuple of unknown type or if a schema was changed concurrently 
(TupleBuilder validated input against outdated schema version), then fallback 
to default logic and re-validate input against the latest schema.

 



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

[jira] [Created] (IGNITE-14555) Calcite engine. Create table from query result

2021-04-15 Thread Konstantin Orlov (Jira)

Konstantin Orlov created IGNITE-14555:
-

 Summary: Calcite engine. Create table from query result
 Key: IGNITE-14555
 URL: https://issues.apache.org/jira/browse/IGNITE-14555
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Konstantin Orlov


Provide ability to create table from the result of the query: {{CREATE TABLE 
my_tbl AS }}.

Affected tests:
{{modules/calcite/src/test/sql/types/decimal/decimal_aggregates.test_ignore}}



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

Re: [DISCUSSION] Error handling in Ignite 3

2021-04-15 Thread Alexei Scherbakov

чт, 15 апр. 2021 г. в 14:26, Ilya Kasnacheev :

> Hello!
>
> > All public methods throw only unchecked
> org.apache.ignite.lang.IgniteException containing aforementioned fields.
> > Each public method must have a section in the javadoc with a list of all
> possible error codes for this method.
>
> I don't think this is feasible at all.
> Imagine javadoc for cache.get() method featuring three pages of possible
> error codes thrown by this method.
>

Of course there is no need to write 3 pages of error codes, this makes no
sense.
I think we can use error ranges here, or, probably, document most important
error scenarios.
The point here is to try to document errors as much as possible.


> Also, updated every two weeks to account for changes in
> underlying mechanisms.
>
> There is still a confusion between "error code for any error in logs" and
> "error code for any pair of method & exception". Which one are we
> discussing really?
>
> This is impossible to track or test, but is susceptible for common
> error-hiding antipattern where all exceptions are caught in cache.get() and
> discarded, and instead a brand new CH-0001 "error in cache.get()" is thrown
> to the user.
>
> Which is certainly not something that anybody wants.
>

Certainly not. We are talking here about root cause - what is exactly the
reason for method call failure.


>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 15 апр. 2021 г. в 13:03, Vladislav Pyatkov :
>
> > Hi Alexei,
> >
> > > Each public method *must *have a section in the javadoc with a list of
> > all possible error codes for this method.
> >
> > I consider it is redundant, because any public exception can be thrown
> from
> > public API.
> > If it not happens today, it may change tomorrow: one will be removed,
> > another one will be added.
> >
> > >Nested exceptions are not forbidden to use. They can provide additional
> > details on the error for debug purposes
> >
> > I see another issue, which is in the Ignite 2.x, but not attend here. We
> > can have a deep nested exception and use it for handling.
> > In the result, all time when we are handling an exception we use
> > pattern like this:
> > try{
> > ...
> > }
> > catch (Exception e) {
> > if (X.hasCause(e, TimeoutException.class))
> > throw e;
> >
> > if (X.hasCause(e, ConnectException.class, EOFException.class))
> > continue;
> >
> > if (X.hasCause(e, InterruptedException.class))
> > return false;
> > }
> >
> > If we have a pant to make only one exception to the client side, we can
> > also do it for an internal exception.
> >
> > On Wed, Apr 14, 2021 at 11:42 AM Alexei Scherbakov <
> > alexey.scherbak...@gmail.com> wrote:
> >
> > > Alexey,
> > >
> > > ср, 14 апр. 2021 г. в 01:52, Alexey Kukushkin <
> kukushkinale...@gmail.com
> > >:
> > >
> > > > Just some points looking questionable to me, although I realize the
> > error
> > > > handling style may be very opinionated:
> > > >
> > > >- Would it make sense splitting the proposed composite error code
> > > >(TBL-0001) into separate numeric code (0001) and scope/category
> > > ("TBL")
> > > > to
> > > >avoid parsing the code when an error handler needs to analyze only
> > the
> > > >category or the code?
> > > >
> > >
> > >   TBL-0001 is a *string representation* of the error. It is built from
> 2
> > > byte scope id (mapped to name TBL) and 2 byte number (0001). Both
> > > internally packed in int. No any kind of parsing will be necessary to
> > read
> > > scope/category.
> > >
> > >
> > > >- "*The cause - short string description of an issue, readable by
> > > > user.*".
> > > >This terminology sounds confusing to me since that "cause" sounds
> > like
> > > > Java
> > > >Throwable's Message to me and the "Cause" is a lower level
> > exception.
> > > >
> > >
> > > The string describes the cause of error, so the name. I'm ok to rename
> it
> > > to a message. It will be stored in IgniteException.message field
> anyway.
> > >
> > >
> > > >- "*The action - steps for a user to resolve error...*". The
> action
> > is
> > > >very important but do we want to make it part of the
> > IgniteException?
> > > I
> > > > do
> > > >not think the recovery action text should be part of the
> exception.
> > > >IgniteException may include a URL pointing to the corresponding
> > > >documentation - this is discussable.
> > > >
> > >
> > > This will not be the part of the exception. A user should visit the
> > > documentation page and read the action section by corresponding error
> > code.
> > >
> > >
> > > >- "*All public methods throw only unchecked IgniteException*" - I
> > > assume
> > > >we still respect JCache specification and prefer using standard
> Java
> > > >exception to signal about invalid parameters.
> > > >
> > >
> > > Using standard java exceptions whenever possible makes sense.
> > >
> > >
> > > >- Why we do not follow the "classic" structured exception handling
> > > >

[jira] [Created] (IGNITE-14554) Calcite engine. Provide ability to parse huge numeric literals

2021-04-15 Thread Konstantin Orlov (Jira)

Konstantin Orlov created IGNITE-14554:
-

 Summary: Calcite engine. Provide ability to parse huge numeric 
literals
 Key: IGNITE-14554
 URL: https://issues.apache.org/jira/browse/IGNITE-14554
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Konstantin Orlov


Currently literals like this {{17014118346046923173168730371588410572}} can't 
pass validation because they overflow range of long values.



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

[jira] [Created] (IGNITE-14553) Calcite engine. Duplicated result on insert

2021-04-15 Thread Konstantin Orlov (Jira)

Konstantin Orlov created IGNITE-14553:
-

 Summary: Calcite engine. Duplicated result on insert
 Key: IGNITE-14553
 URL: https://issues.apache.org/jira/browse/IGNITE-14553
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Konstantin Orlov


Please see the test 
{{modules/calcite/src/test/sql/types/string/test_scan_big_varchar.test_ignore}}



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

[jira] [Created] (IGNITE-14552) Calcite engine. Alias for function CHARACTER_LENGTH

2021-04-15 Thread Konstantin Orlov (Jira)

Konstantin Orlov created IGNITE-14552:
-

 Summary: Calcite engine. Alias for function CHARACTER_LENGTH
 Key: IGNITE-14552
 URL: https://issues.apache.org/jira/browse/IGNITE-14552
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Konstantin Orlov


Currently the function to get the length of the string is named 
{{CHARACTER_LENGTH}}. It would be nice to have an alias {{LENGTH}} for this.



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

[jira] [Created] (IGNITE-14551) NodeJS Thin Client - Error: Invalid response id: in ClientSocket.js

2021-04-15 Thread Dheeraj Saini (Jira)

Dheeraj Saini created IGNITE-14551:
--

 Summary: NodeJS Thin Client - Error: Invalid response id: in 
ClientSocket.js
 Key: IGNITE-14551
 URL: https://issues.apache.org/jira/browse/IGNITE-14551
 Project: Ignite
  Issue Type: Bug
Reporter: Dheeraj Saini
 Attachments: image-2021-04-15-18-45-27-387.png

We are using NodeJS Thin client to connect with ignite node. When we run single 
query to get data from ignite we are able to get data but when we try to get 10 
query per sec we getting below error random times.

 

debug - Error: Invalid response id: 4122254909997320969    at 
/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:344:28   
 at Map.forEach ()    at ClientSocket._disconnect 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:343:24) 
   at Socket. 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:170:22) 
   at runMicrotasks ()    at processTicksAndRejections 
(internal/process/task_queues.js:97:5)[2021-04-15T04:28:51.812] [INFO] debug - 
Error: Invalid response id: 4122254909997320969    at 
/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:344:28   
 at Map.forEach ()    at ClientSocket._disconnect 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:343:24) 
   at Socket. 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:170:22) 
   at runMicrotasks ()    at processTicksAndRejections 
(internal/process/task_queues.js:97:5)[2021-04-15T04:28:51.812] [INFO] debug - 
Error: Invalid response id: 4122254909997320969    at 
/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:344:28   
 at Map.forEach ()    at ClientSocket._disconnect 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:343:24) 
   at Socket. 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:170:22) 
   at runMicrotasks ()    at processTicksAndRejections 
(internal/process/task_queues.js:97:5)[2021-04-15T04:28:51.813] [INFO] debug - 
Error: Type type code 0 is not supported    at Function.unsupportedTypeError 
(/webapp/node_modules/apache-ignite-client/lib/Errors.js:36:16)    at 
BinaryCommunicator._readTypedObject 
(/webapp/node_modules/apache-ignite-client/lib/internal/BinaryCommunicator.js:216:48)
    at BinaryCommunicator.readObject 
(/webapp/node_modules/apache-ignite-client/lib/internal/BinaryCommunicator.js:66:27)
    at SqlFieldsCursor._readRow 
(/webapp/node_modules/apache-ignite-client/lib/Cursor.js:300:50)    at 
runMicrotasks ()    at processTicksAndRejections 
(internal/process/task_queues.js:97:5)    at async SqlFieldsCursor._read 
(/webapp/node_modules/apache-ignite-client/lib/Cursor.js:187:31)    at async 
SqlFieldsCursor._getValues 
(/webapp/node_modules/apache-ignite-client/lib/Cursor.js:151:9)    at async 
SqlFieldsCursor.getValue 
(/webapp/node_modules/apache-ignite-client/lib/Cursor.js:47:13)    at async 
SqlFieldsCursor.getValue 
(/webapp/node_modules/apache-ignite-client/lib/Cursor.js:217:16)    at async 
Function.igniteDatabase.getdata (/webapp/ignite.js:211:20)    at async filter 
(/webapp/htpl/search.js:630:25)[2021-04-15T04:28:51.940] [INFO] debug - Error: 
Ignite client is not in an appropriate state for the requested operation    at 
ClientFailoverSocket.send 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientFailoverSocket.js:47:19)
    at BinaryCommunicator.send 
(/webapp/node_modules/apache-ignite-client/lib/internal/BinaryCommunicator.js:56:28)
    at CacheClient.query 
(/webapp/node_modules/apache-ignite-client/lib/CacheClient.js:538:34)    at 
Function.igniteDatabase.getdata (/webapp/ignite.js:206:48)    at filter 
(/webapp/htpl/search.js:630:46)    at runMicrotasks ()    at 
processTicksAndRejections 
(internal/process/task_queues.js:97:5)[2021-04-15T04:28:51.941] [INFO] debug - 
Error: Ignite client is not in an appropriate state for the requested operation 
   at ClientFailoverSocket.send 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientFailoverSocket.js:47:19)
    at BinaryCommunicator.send 
(/webapp/node_modules/apache-ignite-client/lib/internal/BinaryCommunicator.js:56:28)
    at CacheClient.query 
(/webapp/node_modules/apache-ignite-client/lib/CacheClient.js:538:34)    at 
Function.igniteDatabase.getdata (/webapp/ignite.js:206:48)    at filter 
(/webapp/htpl/search.js:630:46)    at runMicrotasks ()    at 
processTicksAndRejections 
(internal/process/task_queues.js:97:5)[2021-04-15T04:28:51.941] [INFO] debug - 
Error: Ignite client is not in an appropriate state for the requested operation 
   at ClientFailoverSocket.send 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientFailoverSocket.js:47:19)
    at BinaryCommunicator.send 
(/webapp/node_modules/apache-ignite-client/lib/internal/BinaryCommunicator.js:56:28)
    at CacheClient.query

[jira] [Created] (IGNITE-14550) NodeJS Thin Client: Invalid response id: in ClientSocket.js

2021-04-15 Thread Dheeraj Saini (Jira)

Dheeraj Saini created IGNITE-14550:
--

 Summary: NodeJS Thin Client: Invalid response id: in 
ClientSocket.js
 Key: IGNITE-14550
 URL: https://issues.apache.org/jira/browse/IGNITE-14550
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.9
Reporter: Dheeraj Saini
 Attachments: image-2021-04-15-18-40-32-507.png

Hi Team,

 

We are using NodeJS Thin client to connect with ignite node. When we run single 
query to get data from ignite we are able to get data but when we try to get 10 
query per sec we getting below error random times.

 

debug - Error: Invalid response id: 4122254909997320969    at 
/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:344:28   
 at Map.forEach ()    at ClientSocket._disconnect 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:343:24) 
   at Socket. 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:170:22) 
   at runMicrotasks ()    at processTicksAndRejections 
(internal/process/task_queues.js:97:5)[2021-04-15T04:28:51.812] [INFO] debug - 
Error: Invalid response id: 4122254909997320969    at 
/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:344:28   
 at Map.forEach ()    at ClientSocket._disconnect 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:343:24) 
   at Socket. 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:170:22) 
   at runMicrotasks ()    at processTicksAndRejections 
(internal/process/task_queues.js:97:5)[2021-04-15T04:28:51.812] [INFO] debug - 
Error: Invalid response id: 4122254909997320969    at 
/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:344:28   
 at Map.forEach ()    at ClientSocket._disconnect 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:343:24) 
   at Socket. 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientSocket.js:170:22) 
   at runMicrotasks ()    at processTicksAndRejections 
(internal/process/task_queues.js:97:5)[2021-04-15T04:28:51.813] [INFO] debug - 
Error: Type type code 0 is not supported    at Function.unsupportedTypeError 
(/webapp/node_modules/apache-ignite-client/lib/Errors.js:36:16)    at 
BinaryCommunicator._readTypedObject 
(/webapp/node_modules/apache-ignite-client/lib/internal/BinaryCommunicator.js:216:48)
    at BinaryCommunicator.readObject 
(/webapp/node_modules/apache-ignite-client/lib/internal/BinaryCommunicator.js:66:27)
    at SqlFieldsCursor._readRow 
(/webapp/node_modules/apache-ignite-client/lib/Cursor.js:300:50)    at 
runMicrotasks ()    at processTicksAndRejections 
(internal/process/task_queues.js:97:5)    at async SqlFieldsCursor._read 
(/webapp/node_modules/apache-ignite-client/lib/Cursor.js:187:31)    at async 
SqlFieldsCursor._getValues 
(/webapp/node_modules/apache-ignite-client/lib/Cursor.js:151:9)    at async 
SqlFieldsCursor.getValue 
(/webapp/node_modules/apache-ignite-client/lib/Cursor.js:47:13)    at async 
SqlFieldsCursor.getValue 
(/webapp/node_modules/apache-ignite-client/lib/Cursor.js:217:16)    at async 
Function.igniteDatabase.getdata (/webapp/ignite.js:211:20)    at async filter 
(/webapp/htpl/search.js:630:25)[2021-04-15T04:28:51.940] [INFO] debug - Error: 
Ignite client is not in an appropriate state for the requested operation    at 
ClientFailoverSocket.send 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientFailoverSocket.js:47:19)
    at BinaryCommunicator.send 
(/webapp/node_modules/apache-ignite-client/lib/internal/BinaryCommunicator.js:56:28)
    at CacheClient.query 
(/webapp/node_modules/apache-ignite-client/lib/CacheClient.js:538:34)    at 
Function.igniteDatabase.getdata (/webapp/ignite.js:206:48)    at filter 
(/webapp/htpl/search.js:630:46)    at runMicrotasks ()    at 
processTicksAndRejections 
(internal/process/task_queues.js:97:5)[2021-04-15T04:28:51.941] [INFO] debug - 
Error: Ignite client is not in an appropriate state for the requested operation 
   at ClientFailoverSocket.send 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientFailoverSocket.js:47:19)
    at BinaryCommunicator.send 
(/webapp/node_modules/apache-ignite-client/lib/internal/BinaryCommunicator.js:56:28)
    at CacheClient.query 
(/webapp/node_modules/apache-ignite-client/lib/CacheClient.js:538:34)    at 
Function.igniteDatabase.getdata (/webapp/ignite.js:206:48)    at filter 
(/webapp/htpl/search.js:630:46)    at runMicrotasks ()    at 
processTicksAndRejections 
(internal/process/task_queues.js:97:5)[2021-04-15T04:28:51.941] [INFO] debug - 
Error: Ignite client is not in an appropriate state for the requested operation 
   at ClientFailoverSocket.send 
(/webapp/node_modules/apache-ignite-client/lib/internal/ClientFailoverSocket.js:47:19)
    at BinaryCommunicator.send 
(/webapp/node_modules/apache-ignite-client/lib/internal/BinaryCommunicator.js:56:28)
    at

Welcome letter

2021-04-15 Thread Eduard Rakhmankulov

Hello Ignite Community!

My name is Eduard. I want to contribute to Apache Ignite, my JIRA username
*erixon*.

Thanks!

-- 
Best regards, Eduard.

Re: Re[2]: [DISCUSSION] MaxLineLength checkstyle rule

2021-04-15 Thread Ivan Daschinsky

But super long lines are a real problem while merging. It is super
inconvenient.
120 chars is a good compromise.

чт, 15 апр. 2021 г. в 14:39, Zhenya Stanilovsky :

>
> Python is not so verbose as java )
> +1 for 140
>
> >Hi!
> >Personally, I suppose that 120 chars per line is OK. Moreover, many
> >codestyles suggests less chars per line.
> >For example PEP8 recommends 80 (but we use 120 in pyignite and flake8
> >codestyle checks it). Google java codestyle insists on 100.
> >
> >More than 120 chars is too long as for me and is not convenient for 3-way
> >merges.
> >
> >чт, 15 апр. 2021 г. в 12:28, Nikolay Izhikov < nizhi...@apache.org >:
> >
> >> Hello, Ilya.
> >>
> >> Thanks for the feedback.
> >>
> >> 140 characters is fine for me.
> >>
> >> > 15 апр. 2021 г., в 12:25, Ilya Kasnacheev < ilya.kasnach...@gmail.com
> >
> >> написал(а):
> >> >
> >> > Hello!
> >> >
> >> > Please find attached the distribution of line lengths in the project,
> in
> >> the form of (count, line length).
> >> >
> >> > I think that we can enforce a hard limit of 140 chars per line. I
> think
> >> that having longer lines is excessive and does not benefit readability.
> >> >
> >> > Having a limit of 150 or 180 does not give us much since there's still
> >> a long tail which has to be fixed.
> >> >
> >> > Regards,
> >> > --
> >> > Ilya Kasnacheev
> >> >
> >> >
> >> > чт, 15 апр. 2021 г. в 11:30, Nikolay Izhikov < nizhi...@apache.org >:
> >> > Hello, Igniters.
> >> >
> >> > Right now, we have a code style rule [1] - the line should fit in 120
> >> characters.
> >> > But, this rule violated in many and many places through code.
> >> > I have a plan to add a check style rule to force maximum line length.
> >> >
> >> > For me, personally, 120 characters a bit old-fashioned restriction.
> >> > Should we increase the maximum line length to 150 or even 180
> characters?
> >> >
> >> > [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> >> > 
> >>
> >>
> >--
> >Sincerely yours, Ivan Daschinskiy
>
>
>
>



-- 
Sincerely yours, Ivan Daschinskiy

Re[2]: [DISCUSSION] MaxLineLength checkstyle rule

2021-04-15 Thread Zhenya Stanilovsky


Python is not so verbose as java )
+1 for 140
 
>Hi!
>Personally, I suppose that 120 chars per line is OK. Moreover, many
>codestyles suggests less chars per line.
>For example PEP8 recommends 80 (but we use 120 in pyignite and flake8
>codestyle checks it). Google java codestyle insists on 100.
>
>More than 120 chars is too long as for me and is not convenient for 3-way
>merges.
>
>чт, 15 апр. 2021 г. в 12:28, Nikolay Izhikov < nizhi...@apache.org >:
> 
>> Hello, Ilya.
>>
>> Thanks for the feedback.
>>
>> 140 characters is fine for me.
>>
>> > 15 апр. 2021 г., в 12:25, Ilya Kasnacheev < ilya.kasnach...@gmail.com >
>> написал(а):
>> >
>> > Hello!
>> >
>> > Please find attached the distribution of line lengths in the project, in
>> the form of (count, line length).
>> >
>> > I think that we can enforce a hard limit of 140 chars per line. I think
>> that having longer lines is excessive and does not benefit readability.
>> >
>> > Having a limit of 150 or 180 does not give us much since there's still
>> a long tail which has to be fixed.
>> >
>> > Regards,
>> > --
>> > Ilya Kasnacheev
>> >
>> >
>> > чт, 15 апр. 2021 г. в 11:30, Nikolay Izhikov < nizhi...@apache.org >:
>> > Hello, Igniters.
>> >
>> > Right now, we have a code style rule [1] - the line should fit in 120
>> characters.
>> > But, this rule violated in many and many places through code.
>> > I have a plan to add a check style rule to force maximum line length.
>> >
>> > For me, personally, 120 characters a bit old-fashioned restriction.
>> > Should we increase the maximum line length to 150 or even 180 characters?
>> >
>> > [1]  https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
>> > 
>>
>>
>--
>Sincerely yours, Ivan Daschinskiy

[jira] [Created] (IGNITE-14549) Calcite. ORDER BY column not from SELECT LIST

2021-04-15 Thread Konstantin Orlov (Jira)

Konstantin Orlov created IGNITE-14549:
-

 Summary: Calcite. ORDER BY column not from SELECT LIST
 Key: IGNITE-14549
 URL: https://issues.apache.org/jira/browse/IGNITE-14549
 Project: Ignite
  Issue Type: Bug
Reporter: Konstantin Orlov
Assignee: Konstantin Orlov


Currently queries with sorting by a column not presented in select list are 
failed during planning.

{{select col1 from my_table order by col2}}



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

Re: [DISCUSSION] MaxLineLength checkstyle rule

2021-04-15 Thread Nikolay Izhikov

> I think that we should keep the "soft" 120 chars limit in CC, but introduce a 
> hard limit of 140 in checkstyle

Works for me.

> 15 апр. 2021 г., в 14:21, Ilya Kasnacheev  
> написал(а):
> 
> Hello!
> 
> Let me clarify: I think that we should keep the "soft" 120 chars limit in
> CC, but introduce a hard limit of 140 in checkstyle, since it should not be
> too much work or annoy too much.
> 
> In the future we may wish to harmonize the two.
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> чт, 15 апр. 2021 г. в 12:37, Ivan Daschinsky :
> 
>> Hi!
>> Personally, I suppose that 120 chars per line is OK. Moreover, many
>> codestyles suggests less chars per line.
>> For example PEP8 recommends 80 (but we use 120 in pyignite and flake8
>> codestyle checks it). Google java codestyle insists on 100.
>> 
>> More than 120 chars is too long as for me and is not convenient for 3-way
>> merges.
>> 
>> чт, 15 апр. 2021 г. в 12:28, Nikolay Izhikov :
>> 
>>> Hello, Ilya.
>>> 
>>> Thanks for the feedback.
>>> 
>>> 140 characters is fine for me.
>>> 
 15 апр. 2021 г., в 12:25, Ilya Kasnacheev 
>>> написал(а):
 
 Hello!
 
 Please find attached the distribution of line lengths in the project,
>> in
>>> the form of (count, line length).
 
 I think that we can enforce a hard limit of 140 chars per line. I think
>>> that having longer lines is excessive and does not benefit readability.
 
 Having a limit of 150 or 180 does not give us much since there's still
>>> a long tail which has to be fixed.
 
 Regards,
 --
 Ilya Kasnacheev
 
 
 чт, 15 апр. 2021 г. в 11:30, Nikolay Izhikov :
 Hello, Igniters.
 
 Right now, we have a code style rule [1] - the line should fit in 120
>>> characters.
 But, this rule violated in many and many places through code.
 I have a plan to add a check style rule to force maximum line length.
 
 For me, personally, 120 characters a bit old-fashioned restriction.
 Should we increase the maximum line length to 150 or even 180
>> characters?
 
 [1]
>> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
 
>>> 
>>> 
>> 
>> --
>> Sincerely yours, Ivan Daschinskiy
>>

Re: [DISCUSSION] Error handling in Ignite 3

2021-04-15 Thread Ilya Kasnacheev

Hello!

> All public methods throw only unchecked
org.apache.ignite.lang.IgniteException containing aforementioned fields.
> Each public method must have a section in the javadoc with a list of all
possible error codes for this method.

I don't think this is feasible at all.
Imagine javadoc for cache.get() method featuring three pages of possible
error codes thrown by this method.
Also, updated every two weeks to account for changes in
underlying mechanisms.

There is still a confusion between "error code for any error in logs" and
"error code for any pair of method & exception". Which one are we
discussing really?

This is impossible to track or test, but is susceptible for common
error-hiding antipattern where all exceptions are caught in cache.get() and
discarded, and instead a brand new CH-0001 "error in cache.get()" is thrown
to the user.

Which is certainly not something that anybody wants.

Regards,
-- 
Ilya Kasnacheev


чт, 15 апр. 2021 г. в 13:03, Vladislav Pyatkov :

> Hi Alexei,
>
> > Each public method *must *have a section in the javadoc with a list of
> all possible error codes for this method.
>
> I consider it is redundant, because any public exception can be thrown from
> public API.
> If it not happens today, it may change tomorrow: one will be removed,
> another one will be added.
>
> >Nested exceptions are not forbidden to use. They can provide additional
> details on the error for debug purposes
>
> I see another issue, which is in the Ignite 2.x, but not attend here. We
> can have a deep nested exception and use it for handling.
> In the result, all time when we are handling an exception we use
> pattern like this:
> try{
> ...
> }
> catch (Exception e) {
> if (X.hasCause(e, TimeoutException.class))
> throw e;
>
> if (X.hasCause(e, ConnectException.class, EOFException.class))
> continue;
>
> if (X.hasCause(e, InterruptedException.class))
> return false;
> }
>
> If we have a pant to make only one exception to the client side, we can
> also do it for an internal exception.
>
> On Wed, Apr 14, 2021 at 11:42 AM Alexei Scherbakov <
> alexey.scherbak...@gmail.com> wrote:
>
> > Alexey,
> >
> > ср, 14 апр. 2021 г. в 01:52, Alexey Kukushkin  >:
> >
> > > Just some points looking questionable to me, although I realize the
> error
> > > handling style may be very opinionated:
> > >
> > >- Would it make sense splitting the proposed composite error code
> > >(TBL-0001) into separate numeric code (0001) and scope/category
> > ("TBL")
> > > to
> > >avoid parsing the code when an error handler needs to analyze only
> the
> > >category or the code?
> > >
> >
> >   TBL-0001 is a *string representation* of the error. It is built from 2
> > byte scope id (mapped to name TBL) and 2 byte number (0001). Both
> > internally packed in int. No any kind of parsing will be necessary to
> read
> > scope/category.
> >
> >
> > >- "*The cause - short string description of an issue, readable by
> > > user.*".
> > >This terminology sounds confusing to me since that "cause" sounds
> like
> > > Java
> > >Throwable's Message to me and the "Cause" is a lower level
> exception.
> > >
> >
> > The string describes the cause of error, so the name. I'm ok to rename it
> > to a message. It will be stored in IgniteException.message field anyway.
> >
> >
> > >- "*The action - steps for a user to resolve error...*". The action
> is
> > >very important but do we want to make it part of the
> IgniteException?
> > I
> > > do
> > >not think the recovery action text should be part of the exception.
> > >IgniteException may include a URL pointing to the corresponding
> > >documentation - this is discussable.
> > >
> >
> > This will not be the part of the exception. A user should visit the
> > documentation page and read the action section by corresponding error
> code.
> >
> >
> > >- "*All public methods throw only unchecked IgniteException*" - I
> > assume
> > >we still respect JCache specification and prefer using standard Java
> > >exception to signal about invalid parameters.
> > >
> >
> > Using standard java exceptions whenever possible makes sense.
> >
> >
> > >- Why we do not follow the "classic" structured exception handling
> > >practices in Ignite:
> > >
> >
> > Ignite 3 will be multi language, and other languages use other error
> > processing models. SQL for example uses error codes.
> > The single exception approach simplifies and unifies error handling
> across
> > platforms for me.
> >
> >
> > >   - Why do we not allow using checked exceptions? It seems to me
> > >   sometimes forcing the user to handle an error serves as a hint
> and
> > > thus
> > >   improves usability. For example, handling an
> optimistic/pessimistic
> > >   transaction conflict/deadlock. Or handling a timeout for
> operations
> > > with
> > >   timeouts.
> > >
> >
> > A valid point. Checked exceptions must be used for whose

Re: [DISCUSSION] MaxLineLength checkstyle rule

2021-04-15 Thread Ilya Kasnacheev

Hello!

Let me clarify: I think that we should keep the "soft" 120 chars limit in
CC, but introduce a hard limit of 140 in checkstyle, since it should not be
too much work or annoy too much.

In the future we may wish to harmonize the two.

Regards,
-- 
Ilya Kasnacheev


чт, 15 апр. 2021 г. в 12:37, Ivan Daschinsky :

> Hi!
> Personally, I suppose that 120 chars per line is OK. Moreover, many
> codestyles suggests less chars per line.
> For example PEP8 recommends 80 (but we use 120 in pyignite and flake8
> codestyle checks it). Google java codestyle insists on 100.
>
> More than 120 chars is too long as for me and is not convenient for 3-way
> merges.
>
> чт, 15 апр. 2021 г. в 12:28, Nikolay Izhikov :
>
> > Hello, Ilya.
> >
> > Thanks for the feedback.
> >
> > 140 characters is fine for me.
> >
> > > 15 апр. 2021 г., в 12:25, Ilya Kasnacheev 
> > написал(а):
> > >
> > > Hello!
> > >
> > > Please find attached the distribution of line lengths in the project,
> in
> > the form of (count, line length).
> > >
> > > I think that we can enforce a hard limit of 140 chars per line. I think
> > that having longer lines is excessive and does not benefit readability.
> > >
> > >  Having a limit of 150 or 180 does not give us much since there's still
> > a long tail which has to be fixed.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > чт, 15 апр. 2021 г. в 11:30, Nikolay Izhikov :
> > > Hello, Igniters.
> > >
> > > Right now, we have a code style rule [1] - the line should fit in 120
> > characters.
> > > But, this rule violated in many and many places through code.
> > > I have a plan to add a check style rule to force maximum line length.
> > >
> > > For me, personally, 120 characters a bit old-fashioned restriction.
> > > Should we increase the maximum line length to 150 or even 180
> characters?
> > >
> > > [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > > 
> >
> >
>
> --
> Sincerely yours, Ivan Daschinskiy
>

Re: IEP-70: Async Continuation Executor

2021-04-15 Thread Stanislav Lukyanov

Giving this another thought - I'm kinda torn on this myself now, as I like you 
argument that a chain of multiple (GG and not GG) continuations should execute 
in the same pool.
This would probably be easier to understand for a beginning or intermediate 
Ignite user, which is the majority.
Anyway, I'll leave to you to decide. 

> On 15 Apr 2021, at 11:02, Stanislav Lukyanov  wrote:
> 
> Hi Pavel,
> 
> I'd prefer public pool.
> 
> Thanks,
> Stan
> 
>> On 12 Apr 2021, at 20:17, Pavel Tupitsyn  wrote:
>> 
>> Stan,
>> 
>> Sorry for the late reply (had a vacation).
>> 
>>> In my ideal world, the users don't configure thread pools, they just have
>> safe default behavior (async execution)
>>> and a way to make it fast for one particular function (with annotation or
>> anything else).
>> 
>> I've
>> added 
>> testRemoteOperationListenerExecutesOnStripedPoolWhenCustomExecutorIsProvided
>> to demonstrate this use case.
>> 
>> 
>>> I'm OK to proceed with the approach you're suggesting if I haven't
>> convinced you by now
>> 
>> Are you OK to merge the changes as is (ForkJoinPool#commonPool as the
>> default executor),
>> or do we change it to Ignite public pool?
>> 
>> On Mon, Mar 29, 2021 at 11:09 PM Stanislav Lukyanov 
>> wrote:
>> 
>>> But what if I need to have exactly one callback synchronous, and all other
>>> can be asynchronous?
>>> 
>>> I would separate two cases: an existing user who wants their old behavior
>>> back, and a new user that wants to fine tune their app.
>>> The existing user needs a global "make it all synchronous" switch.
>>> The new user should only enable the fast-but-dangerous behavior locally,
>>> exactly where they need it.
>>> 
>>> In my ideal world, the users don't configure thread pools, they just have
>>> safe default behavior (async execution)
>>> and a way to make it fast for one particular function (with annotation or
>>> anything else).
>>> Also, this should work in a similar way for different APIs - so I'm trying
>>> to lay some basis to rework all of these continuous queries and event
>>> listeners,
>>> even though they're explicitly mentioned as out of scope for IEP-70.
>>> 
>>> At the same time, I understand that any change we make now will have pros
>>> and cons, and we can't make it perfect because of compatibility reasons.
>>> I'm OK to proceed with the approach you're suggesting if I haven't
>>> convinced you by now :)
>>> 
>>> Thanks,
>>> Stan
>>> 
 On 29 Mar 2021, at 22:47, Pavel Tupitsyn  wrote:
 
 Stan,
 
 Unfortunately, annotations have a few drawbacks:
 * Can't configure it globally ("I already use sync callbacks, give me
>>> back
 the old behavior in one line")
 * Can't configure in Spring
 * Useless in C++ & .NET
 * You can already specify executor in IgniteFuture#listenAsync, so there
 seems to be no added value
 
> the only value we really expect the user to set in that property is
 Runnable::run
 Not really - there are lots of available options [1].
 Some apps may already have one or more thread pools that can be used for
 continuations.
 
> you can't specify Runnable::run in a Spring XML
 Good point, but creating a class for that is trivial.
 We can ship a ready-made class and mention it in the docs for simplicity.
 
 
 Globally configurable Executor fits nicely with
 existing IgniteFuture#listenAsync,
 not sure why you dislike it.
 
 
 [1]
 
>>> https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html
 
 On Mon, Mar 29, 2021 at 10:23 PM Stanislav Lukyanov <
>>> stanlukya...@gmail.com>
 wrote:
 
> Thought about this some more.
> 
> I agree that we need to be able to switch to synchronous listeners when
> it's critical for performance.
> However, I don't like to introduce an Executor property for that. In
>>> fact,
> the only value
> we really expect the user to set in that property is Runnable::run -
>>> seems
> to be an overkill to have accept an Executor for that.
> Furthermore, you can't specify Runnable::run in a Spring XML, can you?
> 
> I'm thinking that maybe we should go the annotation route here.
> Let's introduce an annotation @IgniteSyncCallback. It's the same as
> @IgniteAsyncCallback but reverse :)
> If a listener is annotated like that then we execute it in the same
> thread; by default, we execute in the public pool.
> We can also reuse the same annotation for all other callbacks we have in
> the system - right now, the callbacks are a mix of sync and async
>>> behavior,
> and we could transition all APIs to use async by default and enforce
>>> sync
> callbacks when the annotation is used.
> @IgniteAsyncCallback should eventually be deprecated.
> 
> WDYT?
> 
> Thanks,
> Stan
> 
>> On 29 Mar 2021, at 14:09, Pavel Tupitsyn  wrote:
>> 
>> Stan,
>> 
>> I'm ok with using

Re: Stop sending IGNITE Created e-mails to dev@

2021-04-15 Thread Ivan Pavlukhin

Hi,

Personally I do not like an idea of excluding notifications for
created JIRA tickets from dev-list. I used such notifications in
following cases:
* React to tickets created by Ignite users in my area of responsibility.
* Redirect questions created as JIRA tickets to user-list.
* Trash spam tickets.

Perhaps personally subscribing to "Created" notifications in JIRA is
fine (I have not found how), but I am not sure what should be a
default behavior. Perhaps we can revisit iss...@ignite.apache.org list
content and leave only "Created" notifications there as I doubt that
anyone really uses this list today.

2021-04-14 21:26 GMT+03:00, Maxim Muzafarov :
> +1 for new JIRA issues
> -1 for MTCGA notifications
>
> Why we should hide errors from the dev-list? Who should take care of
> issues reported by MTCGA.Bot in this case?
> We must apply stricter rules for such issues: a commit leading to an
> error must be reverted.
>
> On Wed, 14 Apr 2021 at 20:00, Denis Mekhanikov 
> wrote:
>>
>> Huge +1 to this.
>>
>> I've already brought up this topic in the past:
>> http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html
>> I hope some day newcomers won't need to set up their email filters when
>> they come to the developers list.
>>
>> Denis
>>
>> ср, 14 апр. 2021 г. в 18:07, Atri Sharma :
>>
>> > +1 to move issues to the issues list.
>> >
>> > For MTCGA, maybe build@?
>> >
>> > On Wed, Apr 14, 2021 at 8:35 PM Ilya Kasnacheev 
>> > wrote:
>> > >
>> > > Hello!
>> > >
>> > > We have a discussion on how to ensure best engagement in dev@ list,
>> > > and
>> > it
>> > > seems that Issue Created emails from IGNITE project consume a lot of
>> > screen
>> > > space, it's hard to spot genuine discussions in
>> > > https://lists.apache.org/list.html?dev@ignite.apache.org for example.
>> > >
>> > > We already have issues@ mailing list. I propose that we stop sending
>> > > any
>> > > JIRA emails to dev@. If anyone wishes to get just Created emails,
>> > > they
>> > can
>> > > subscribe to these messages in their JIRA account settings. I imagine
>> > most
>> > > of you already filter these messages out, so you may need to adjust
>> > > your
>> > > filters slightly.
>> > >
>> > > A distant second is MTCGA messages, which are also autogenerated and
>> > > not
>> > > informative for most readers of the channel, since they are at best
>> > > targeted at a single committer and at worst flaky.
>> > >
>> > > Where could we move those? What is your opinion here, on both issues?
>> > >
>> > > Regards,
>> >
>> > --
>> > Regards,
>> >
>> > Atri
>> > Apache Concerted
>> >
>


-- 

Best regards,
Ivan Pavlukhin

[jira] [Created] (IGNITE-14548) BinaryThreadLocalContext must be cleaned when client is closed

2021-04-15 Thread Taras Ledkov (Jira)

Taras Ledkov created IGNITE-14548:
-

 Summary: BinaryThreadLocalContext must be cleaned when client is 
closed
 Key: IGNITE-14548
 URL: https://issues.apache.org/jira/browse/IGNITE-14548
 Project: Ignite
  Issue Type: Bug
  Components: binary
Affects Versions: 2.10
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.11


ThreadLocal {{BinaryThreadLocalContext#CTX}} must be cleaned when thin client 
and JDBC thin client are closed.

Fail case: [Stack 
overflow|https://stackoverflow.com/questions/67086723/unable-to-remove-org-apache-ignite-internal-binary-binarythreadlocal-error-in-we?noredirect=1#comment118615654_67086723]

Previous discussion: IGNITE-967



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

Re: [DISCUSSION] Error handling in Ignite 3

2021-04-15 Thread Vladislav Pyatkov

Hi Alexei,

> Each public method *must *have a section in the javadoc with a list of
all possible error codes for this method.

I consider it is redundant, because any public exception can be thrown from
public API.
If it not happens today, it may change tomorrow: one will be removed,
another one will be added.

>Nested exceptions are not forbidden to use. They can provide additional
details on the error for debug purposes

I see another issue, which is in the Ignite 2.x, but not attend here. We
can have a deep nested exception and use it for handling.
In the result, all time when we are handling an exception we use
pattern like this:
try{
...
}
catch (Exception e) {
if (X.hasCause(e, TimeoutException.class))
throw e;

if (X.hasCause(e, ConnectException.class, EOFException.class))
continue;

if (X.hasCause(e, InterruptedException.class))
return false;
}

If we have a pant to make only one exception to the client side, we can
also do it for an internal exception.

On Wed, Apr 14, 2021 at 11:42 AM Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:

> Alexey,
>
> ср, 14 апр. 2021 г. в 01:52, Alexey Kukushkin :
>
> > Just some points looking questionable to me, although I realize the error
> > handling style may be very opinionated:
> >
> >- Would it make sense splitting the proposed composite error code
> >(TBL-0001) into separate numeric code (0001) and scope/category
> ("TBL")
> > to
> >avoid parsing the code when an error handler needs to analyze only the
> >category or the code?
> >
>
>   TBL-0001 is a *string representation* of the error. It is built from 2
> byte scope id (mapped to name TBL) and 2 byte number (0001). Both
> internally packed in int. No any kind of parsing will be necessary to read
> scope/category.
>
>
> >- "*The cause - short string description of an issue, readable by
> > user.*".
> >This terminology sounds confusing to me since that "cause" sounds like
> > Java
> >Throwable's Message to me and the "Cause" is a lower level exception.
> >
>
> The string describes the cause of error, so the name. I'm ok to rename it
> to a message. It will be stored in IgniteException.message field anyway.
>
>
> >- "*The action - steps for a user to resolve error...*". The action is
> >very important but do we want to make it part of the IgniteException?
> I
> > do
> >not think the recovery action text should be part of the exception.
> >IgniteException may include a URL pointing to the corresponding
> >documentation - this is discussable.
> >
>
> This will not be the part of the exception. A user should visit the
> documentation page and read the action section by corresponding error code.
>
>
> >- "*All public methods throw only unchecked IgniteException*" - I
> assume
> >we still respect JCache specification and prefer using standard Java
> >exception to signal about invalid parameters.
> >
>
> Using standard java exceptions whenever possible makes sense.
>
>
> >- Why we do not follow the "classic" structured exception handling
> >practices in Ignite:
> >
>
> Ignite 3 will be multi language, and other languages use other error
> processing models. SQL for example uses error codes.
> The single exception approach simplifies and unifies error handling across
> platforms for me.
>
>
> >   - Why do we not allow using checked exceptions? It seems to me
> >   sometimes forcing the user to handle an error serves as a hint and
> > thus
> >   improves usability. For example, handling an optimistic/pessimistic
> >   transaction conflict/deadlock. Or handling a timeout for operations
> > with
> >   timeouts.
> >
>
> A valid point. Checked exceptions must be used for whose methods, where
> error handling is enforced, for example tx optimistic failure.
> Such errors will also have corresponding error codes.
>
>
> >   - Why single public IgniteException and no exception hierarchy?
> Java
> >   is optimized for structured exception handling instead of using
> > IF-ELSE to
> >   analyze the codes.
> >
>
> Exception hierarchy is not required when using error codes and applicable
> only to java API, so I would avoid spending efforts on it.
>
>
> >   - Why no nested exceptions? Sometimes an error handler is
> interested
> >   only in high level exceptions (like Invalid Configuration) and
> > sometimes
> >   details are needed (like specific configuration parser exceptions).
> >
>
> Nested exceptions are not forbidden to use. They can provide additional
> details on the error for debug purposes, but not strictly required, because
> error code + message should provide enough information to the user.
>
>
> >- For async methods returning a Future we may have a universal rule on
> >how to handle exceptions. For example, we may specify that any async
> > method
> >can throw only invalid argument exceptions. All other errors are
> > reported
> >via the

Re: [DISCUSSION] MaxLineLength checkstyle rule

2021-04-15 Thread Ivan Daschinsky

Hi!
Personally, I suppose that 120 chars per line is OK. Moreover, many
codestyles suggests less chars per line.
For example PEP8 recommends 80 (but we use 120 in pyignite and flake8
codestyle checks it). Google java codestyle insists on 100.

More than 120 chars is too long as for me and is not convenient for 3-way
merges.

чт, 15 апр. 2021 г. в 12:28, Nikolay Izhikov :

> Hello, Ilya.
>
> Thanks for the feedback.
>
> 140 characters is fine for me.
>
> > 15 апр. 2021 г., в 12:25, Ilya Kasnacheev 
> написал(а):
> >
> > Hello!
> >
> > Please find attached the distribution of line lengths in the project, in
> the form of (count, line length).
> >
> > I think that we can enforce a hard limit of 140 chars per line. I think
> that having longer lines is excessive and does not benefit readability.
> >
> >  Having a limit of 150 or 180 does not give us much since there's still
> a long tail which has to be fixed.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 15 апр. 2021 г. в 11:30, Nikolay Izhikov :
> > Hello, Igniters.
> >
> > Right now, we have a code style rule [1] - the line should fit in 120
> characters.
> > But, this rule violated in many and many places through code.
> > I have a plan to add a check style rule to force maximum line length.
> >
> > For me, personally, 120 characters a bit old-fashioned restriction.
> > Should we increase the maximum line length to 150 or even 180 characters?
> >
> > [1] https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
> > 
>
>

-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSSION] MaxLineLength checkstyle rule

2021-04-15 Thread Nikolay Izhikov

Hello, Ilya.

Thanks for the feedback.

140 characters is fine for me.

> 15 апр. 2021 г., в 12:25, Ilya Kasnacheev  
> написал(а):
> 
> Hello!
> 
> Please find attached the distribution of line lengths in the project, in the 
> form of (count, line length).
> 
> I think that we can enforce a hard limit of 140 chars per line. I think that 
> having longer lines is excessive and does not benefit readability.
> 
>  Having a limit of 150 or 180 does not give us much since there's still a 
> long tail which has to be fixed.
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> чт, 15 апр. 2021 г. в 11:30, Nikolay Izhikov :
> Hello, Igniters.
> 
> Right now, we have a code style rule [1] - the line should fit in 120 
> characters.
> But, this rule violated in many and many places through code.
> I have a plan to add a check style rule to force maximum line length.
> 
> For me, personally, 120 characters a bit old-fashioned restriction.
> Should we increase the maximum line length to 150 or even 180 characters?
> 
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
>

Re: [DISCUSSION] MaxLineLength checkstyle rule

2021-04-15 Thread Ilya Kasnacheev

Hello!

Please find attached the distribution of line lengths in the project, in
the form of (count, line length).

I think that we can enforce a hard limit of 140 chars per line. I think
that having longer lines is excessive and does not benefit readability.

 Having a limit of 150 or 180 does not give us much since there's still a
long tail which has to be fixed.

Regards,
-- 
Ilya Kasnacheev


чт, 15 апр. 2021 г. в 11:30, Nikolay Izhikov :

> Hello, Igniters.
>
> Right now, we have a code style rule [1] - the line should fit in 120
> characters.
> But, this rule violated in many and many places through code.
> I have a plan to add a check style rule to force maximum line length.
>
> For me, personally, 120 characters a bit old-fashioned restriction.
> Should we increase the maximum line length to 150 or even 180 characters?
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
 431236 0
  11229 1
  37934 2
  33466 3
232 4
  90130 5
  27581 6
 121919 7
799 8
  59091 9
  23591 10
  15654 11
   2610 12
  28908 13
   9311 14
   2674 15
   3737 16
  23552 17
   6037 18
  12238 19
  14246 20
  22603 21
  20644 22
  14531 23
  50308 24
  23772 25
  20297 26
  23470 27
  31646 28
  25332 29
  20690 30
  21042 31
  22896 32
  36538 33
  21031 34
  32305 35
  21009 36
  25006 37
  20938 38
  19820 39
  23467 40
  24764 41
  22007 42
  19857 43
  20225 44
  19902 45
  19832 46
  18240 47
  19569 48
  19051 49
  28998 50
  16407 51
  19124 52
  15777 53
  14772 54
  16128 55
  25169 56
  13672 57
  19888 58
  18848 59
  14146 60
  12277 61
  12091 62
  12901 63
  12826 64
  11898 65
  10488 66
  11092 67
  24055 68
  21916 69
  43990 70
  22136 71
  20068 72
   8786 73
  20192 74
  19881 75
  10381 76
   9149 77
   9587 78
   7302 79
   7657 80
   7039 81
   6924 82
   6588 83
   6399 84
   6098 85
   5652 86
   5374 87
   5163 88
   5341 89
   5007 90
   4920 91
   4874 92
   4500 93
   4320 94
   4423 95
   4489 96
   3991 97
   3926 98
   3840 99
   3671 100
   3343 101
   3269 102
   3502 103
   3244 104
   3033 105
   4322 106
   4225 107
   2745 108
   2530 109
   2502 110
   2453 111
   2372 112
   2278 113
   2069 114
   2078 115
   2109 116
   1940 117
   1874 118
   1701 119
   1446 120
955 121
594 122
552 123
470 124
404 125
418 126
316 127
281 128
318 129
228 130
151 131
205 132
162 133
150 134
143 135
131 136
114 137
112 138
 91 139
219 140
 77 141
 55 142
 74 143
 56 144
 47 145
 64 146
 68 147
 61 148
 36 149
 40 150
 29 151
 41 152
 22 153
 36 154
 29 155
 21 156
 18 157
 17 158
 19 159
 12 160
 13 161
  8 162
  7 163
 20 164
 27 165
 20 166
 15 167
 30 168
  6 169
  9 170
  4 171
 13 172
  5 173
 10 174
  8 175
  9 176
 14 177
  7 178
  4 179
  6 180
  4 181
  1 182
  7 183
 10 184
  8 185
  4 186
  5 187
  2 188
  5 189
  3 190
  6 191
  8 192
 11 193
  5 194
  6 195
  4 196
  7 197
  6 198
  7 199
  5 201
  5 202
  9 203
  3 204
  6 205
  9 206
  5 207
  4 208
  5 209
  7 210
  8 211
  7 212
 11 213
  4 214
 10 215
  4 216
 11 217
  5 218
  6 219
  1 220
  6 221
  3 222
 10 223
  1 224
 11 225
  2 226
  5 227
  3 229
  6 231
  1 232
  1 233
  4 234
  3 235
  1 236
  5 237
  7 239
  4 240
  6 241
  1 242
  5 243
  4 244
  2 245
  1 246
  1 247
  1 248
  5 249
  8 251
  1 252
  6 253
  3 255
  3 257
  2 258
  5 259
  2 260
  2 261
  2 263
  1 264
  3 265
  4 267
  1 268
  3 269
  1 272
  1 273
  2 274
  1 275
  1 278
  1 279
  3 283
  1 286
  1 289
  1 292
  2 304
  2 305
  2 306
  2 307
  1 312
  1 316
  3 317
  1 318
  4 319
  3 320
  4 321
  2 322
  2 324
  3 325
  1 326
  3 329
  3 330
  2 331
  1 332
  2 333
  3 334
  1 335
  1 336
  3 337
  1 338
  1 339
  1 340
  3 342
  2 343
  3 345
  3 347
  1 348
  1 349
  2 352
  1 355
  3 360
  3 361
  2 365
  2 366
  1 369
  2 373
  2 377
  2 378
  4 379
  2 380
  1 384
  2 385
  2 386
  1 388
  1 389
  1 391
  3 392
  2 393
  2 394
  1 395
  2 397
  3 398
  3 402
  2 403
  2 407
  2 408
  1 409
  1 412
  2 415
  1 417
  2 420
  1 427
  1 428
  1 431
  2 433
  1 435
  2 438
  1 440
  1 445
  1 446
  1 447
  2 452
  1 454

[DISCUSSION] MaxLineLength checkstyle rule

2021-04-15 Thread Nikolay Izhikov

Hello, Igniters.

Right now, we have a code style rule [1] - the line should fit in 120 
characters.
But, this rule violated in many and many places through code.
I have a plan to add a check style rule to force maximum line length.

For me, personally, 120 characters a bit old-fashioned restriction.
Should we increase the maximum line length to 150 or even 180 characters?

[1] https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines

Re: IEP-70: Async Continuation Executor

2021-04-15 Thread Stanislav Lukyanov

Hi Pavel,

I'd prefer public pool.

Thanks,
Stan

> On 12 Apr 2021, at 20:17, Pavel Tupitsyn  wrote:
> 
> Stan,
> 
> Sorry for the late reply (had a vacation).
> 
>> In my ideal world, the users don't configure thread pools, they just have
> safe default behavior (async execution)
>> and a way to make it fast for one particular function (with annotation or
> anything else).
> 
> I've
> added 
> testRemoteOperationListenerExecutesOnStripedPoolWhenCustomExecutorIsProvided
> to demonstrate this use case.
> 
> 
>> I'm OK to proceed with the approach you're suggesting if I haven't
> convinced you by now
> 
> Are you OK to merge the changes as is (ForkJoinPool#commonPool as the
> default executor),
> or do we change it to Ignite public pool?
> 
> On Mon, Mar 29, 2021 at 11:09 PM Stanislav Lukyanov 
> wrote:
> 
>> But what if I need to have exactly one callback synchronous, and all other
>> can be asynchronous?
>> 
>> I would separate two cases: an existing user who wants their old behavior
>> back, and a new user that wants to fine tune their app.
>> The existing user needs a global "make it all synchronous" switch.
>> The new user should only enable the fast-but-dangerous behavior locally,
>> exactly where they need it.
>> 
>> In my ideal world, the users don't configure thread pools, they just have
>> safe default behavior (async execution)
>> and a way to make it fast for one particular function (with annotation or
>> anything else).
>> Also, this should work in a similar way for different APIs - so I'm trying
>> to lay some basis to rework all of these continuous queries and event
>> listeners,
>> even though they're explicitly mentioned as out of scope for IEP-70.
>> 
>> At the same time, I understand that any change we make now will have pros
>> and cons, and we can't make it perfect because of compatibility reasons.
>> I'm OK to proceed with the approach you're suggesting if I haven't
>> convinced you by now :)
>> 
>> Thanks,
>> Stan
>> 
>>> On 29 Mar 2021, at 22:47, Pavel Tupitsyn  wrote:
>>> 
>>> Stan,
>>> 
>>> Unfortunately, annotations have a few drawbacks:
>>> * Can't configure it globally ("I already use sync callbacks, give me
>> back
>>> the old behavior in one line")
>>> * Can't configure in Spring
>>> * Useless in C++ & .NET
>>> * You can already specify executor in IgniteFuture#listenAsync, so there
>>> seems to be no added value
>>> 
 the only value we really expect the user to set in that property is
>>> Runnable::run
>>> Not really - there are lots of available options [1].
>>> Some apps may already have one or more thread pools that can be used for
>>> continuations.
>>> 
 you can't specify Runnable::run in a Spring XML
>>> Good point, but creating a class for that is trivial.
>>> We can ship a ready-made class and mention it in the docs for simplicity.
>>> 
>>> 
>>> Globally configurable Executor fits nicely with
>>> existing IgniteFuture#listenAsync,
>>> not sure why you dislike it.
>>> 
>>> 
>>> [1]
>>> 
>> https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html
>>> 
>>> On Mon, Mar 29, 2021 at 10:23 PM Stanislav Lukyanov <
>> stanlukya...@gmail.com>
>>> wrote:
>>> 
 Thought about this some more.
 
 I agree that we need to be able to switch to synchronous listeners when
 it's critical for performance.
 However, I don't like to introduce an Executor property for that. In
>> fact,
 the only value
 we really expect the user to set in that property is Runnable::run -
>> seems
 to be an overkill to have accept an Executor for that.
 Furthermore, you can't specify Runnable::run in a Spring XML, can you?
 
 I'm thinking that maybe we should go the annotation route here.
 Let's introduce an annotation @IgniteSyncCallback. It's the same as
 @IgniteAsyncCallback but reverse :)
 If a listener is annotated like that then we execute it in the same
 thread; by default, we execute in the public pool.
 We can also reuse the same annotation for all other callbacks we have in
 the system - right now, the callbacks are a mix of sync and async
>> behavior,
 and we could transition all APIs to use async by default and enforce
>> sync
 callbacks when the annotation is used.
 @IgniteAsyncCallback should eventually be deprecated.
 
 WDYT?
 
 Thanks,
 Stan
 
> On 29 Mar 2021, at 14:09, Pavel Tupitsyn  wrote:
> 
> Stan,
> 
> I'm ok with using public pool by default, but we need a way to restore
 the
> old behavior, do you agree?
> I think we should keep the new IgniteConfiguration property.
> 
> On Fri, Mar 26, 2021 at 2:12 PM Alexei Scherbakov <
> alexey.scherbak...@gmail.com> wrote:
> 
>> Pavel,
>> 
>> Dedicated pool looks safer and more manageable to me. Make sure the
 threads
>> in the pool are lazily started and stopped if not used for some time.
>> 
>> Because I have no more real arguments against

46 matches

Mail list logo