Re: IGNITE-2399 : Asynchronous Acquire method in IgniteSemaphore
Thank you so much! On Thu, Mar 18, 2021 at 3:01 AM Valentin Kulichenko wrote: > > Hi Atri, > > Looks good to me, I've merged the changes. Please resolve the ticket. > > -Val > > On Wed, Mar 17, 2021 at 5:07 AM Atri Sharma wrote: > > > Hi Valentine, > > > > Hoping you are well. > > > > Please let me know if the PR looks ok. > > > > Regards, > > > > Atri > > > > > > On Thu, 11 Mar 2021, 12:09 Atri Sharma, wrote: > > > > > Hi Val, > > > > > > Thanks for taking a look. I have updated the PR, please see and let me > > > know your thoughts and feedback. > > > > > > Regards, > > > > > > Atri > > > > > > On Thu, Mar 11, 2021 at 6:16 AM Valentin Kulichenko > > > wrote: > > > > > > > > Atri, > > > > > > > > I've added my comments to the PR. > > > > > > > > -Val > > > > > > > > On Wed, Mar 10, 2021 at 2:44 AM Atri Sharma wrote: > > > > > > > > > I have just updated the PR: > > > > > > > > > > https://github.com/apache/ignite/pull/8820 > > > > > > > > > > Please review. > > > > > > > > > > On Wed, Mar 10, 2021 at 1:51 PM Atri Sharma wrote: > > > > > > > > > > > > Hi Val, > > > > > > > > > > > > Thank you for taking the time on this one. > > > > > > > > > > > > The main reason as to why I chose that signature was because I felt > > > it > > > > > > gave a clear idea of the interface that the user should expect when > > > > > > using the method. So essentially, the user is providing a callback > > > > > > listener himself/herself and the API is just using that to tie the > > > > > > lifecycle of holding the semaphore. > > > > > > > > > > > > However, I do see your point and feel that the current signature > > that > > > > > > the PR has will limit the usability of the method and make users > > jump > > > > > > through more hoops. I have changed the signature to accept Callable > > > > > > returning T. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Atri > > > > > > > > > > > > On Wed, Mar 10, 2021 at 5:29 AM Valentin Kulichenko > > > > > > wrote: > > > > > > > > > > > > > > Hi Atri, > > > > > > > > > > > > > > First and foremost, we need to clarify the API for this > > > functionality. > > > > > > > There are two options presented in the ticket, but no clear > > > decision > > > > > about > > > > > > > which one should be used. I personally think that the original > > > > > signature > > > > > > > (the one in the ticket description) makes more sense, but it > > looks > > > like > > > > > > > you've implemented an alternative suggested in the comments. What > > > was > > > > > your > > > > > > > motivation behind that? > > > > > > > > > > > > > > As for where the method can be located, I'm OK if we add it > > > directly > > > > > to the > > > > > > > IgniteSemaphore interface. > > > > > > > > > > > > > > -Val > > > > > > > > > > > > > > On Tue, Mar 9, 2021 at 8:22 AM Atri Sharma > > > wrote: > > > > > > > > > > > > > > > Gentle ping > > > > > > > > > > > > > > > > On Mon, 8 Mar 2021, 13:51 Atri Sharma, > > wrote: > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > I would like to start a discussion around IGNITE-2399. > > > > > > > > > > > > > > > > > > Background: The typical use of IgniteSemaphore consists of > > > > > acquiring > > > > > > > > > the semaphore, performing the task and releasing the > > semaphore. > > > > > This > > > > > > > > > JIRA proposes a new method which will accept a callable, > > > acquire > > > > > the > > > > > > > > > semaphore, and return a future. Upon completion of the > > future, > > > the > > > > > > > > > semaphore is released. > > > > > > > > > > > > > > > > > > This API seems useful for an easy encapsulation of the > > > described > > > > > use > > > > > > > > > case and does not cause an internal flux since all the > > changes > > > are > > > > > > > > > focused at the public API. > > > > > > > > > > > > > > > > > > WIP PR for the same: > > > > > > > > > > > > > > > > > > https://github.com/apache/ignite/pull/8820 > > > > > > > > > > > > > > > > > > Please share your thoughts and comments. > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Atri > > > > > > > > > Apache Concerted > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Regards, > > > > > > > > > > > > Atri > > > > > > Apache Concerted > > > > > > > > > > > > > > > > > > > > -- > > > > > Regards, > > > > > > > > > > Atri > > > > > Apache Concerted > > > > > > > > > > > -- > > > Regards, > > > > > > Atri > > > Apache Concerted > > > > > -- Regards, Atri Apache Concerted
Re: How to Contribute 2021
In my mind CONTRIBUTING.md is a nice and quite common starting point for contributors. Other projects use it as well [1], [2]. Also GitHub treats it somehow specially, I recall it suggested me to make familiar with CONTRIBUTING.md of some repo. [1] https://github.com/hazelcast/hazelcast/blob/master/CONTRIBUTING.md [2] https://github.com/apache/cassandra/blob/trunk/CONTRIBUTING.md 2021-03-18 0:32 GMT+03:00, Maxim Muzafarov : > Kseniya, > > From my point of view he contribute.html and CONTRIBUTING.md should be > the same with the reference to the wiki page How_to_Contribute_2021 > describing all the additional details and common issues with the first > contributions. > > I also think it would be better to create special dedicated pages for > committers and contributors. I don't get the idea why we can't do this > keeping the same data as they were on the original How_to_Contribute > page. > > On Tue, 16 Mar 2021 at 13:18, Kseniya Romanova > wrote: >> >> So we do have 3 sources for how to contribute: >> >> 1. https://ignite.apache.org/community/contribute.html >> 2. https://github.com/apache/ignite/blob/master/CONTRIBUTING.md >> 3. >> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute+2021 >> >> Seems that wiki is more technical, right? But is there any reason for 2 >> different versions for GitHub and the website? >> >> вт, 16 мар. 2021 г. в 13:11, Ilya Kasnacheev : >> >> > Hello again! >> > >> > Based on the feedback, I have removed ASCII art from the git section, >> > making it shorter and clearer. >> > >> > Regards, >> > -- >> > Ilya Kasnacheev >> > >> > >> > вт, 16 мар. 2021 г. в 11:47, Ilya Kasnacheev >> > : >> > >> > > Hello, Pavel! >> > > >> > > At the very minimum, a newcomer should be able to run tests on TC or >> > MTCGA. >> > > >> > > Explaining that process takes most of the contribution guide. >> > > >> > > Even if somebody is ready to run those tests for a newcomer once or >> > > twice >> > > (already a long shot, it's hard to even get a simple review), they >> > > have >> > no >> > > opportunity to learn except for this guide. They really don't have >> > anybody >> > > to ask. >> > > >> > > As I have said, I can't create two documents at the same time so if >> > > we >> > > need a separate one for committers, it may only be written after the >> > fact, >> > > and we can't remove essential information in the meantime. >> > > >> > > Regards, >> > > -- >> > > Ilya Kasnacheev >> > > >> > > >> > > пн, 15 мар. 2021 г. в 18:26, Pavel Tupitsyn : >> > > >> > >> Ilya, >> > >> >> > >> Thanks for the effort! >> > >> >> > >> I think this guide should be much shorter and simple. >> > >> Right now it is intimidating for newcomers. >> > >> >> > >> What they need is basically >> > >> * Register in Jira, pick a ticket, assign, put In Progress >> > >> * Create a fork, implement >> > >> * Create a PR >> > >> * Ask for review >> > >> >> > >> Maybe we should have a separate, detailed guide for Committers, >> > >> and a simple one for Contributors? >> > >> >> > >> On Mon, Mar 15, 2021 at 6:19 PM Ilya Kasnacheev < >> > >> ilya.kasnach...@gmail.com> >> > >> wrote: >> > >> >> > >> > Hello! >> > >> > >> > >> > Please see inline. >> > >> > >> > >> > пн, 15 мар. 2021 г. в 18:06, Maxim Muzafarov : >> > >> > >> > >> > > Hello, >> > >> > > >> > >> > > >> > >> > > > Ignite employs both Review-Then-Commit processes. >> > >> > > >> > >> > > The Commit-Then-Review (CTR) removed? >> > >> > > >> > >> > I don't see any applications of CTR during the few last years. >> > Streamers >> > >> > were supposed to be CTR but Saikat Maitra still asked for the >> > >> > review >> > of >> > >> > streamers-related commits. >> > >> > >> > >> > > Information for committers >> > >> > > >> > >> > > Do we need this on a page for newcomers? I'd like to mention >> > >> > > that >> > some >> > >> > > of the committers still use the commit script, however, I think >> > >> > > it >> > >> > > will be better to configure the GitHub interaction. >> > >> > > >> > >> > I don't think there's a separate page for committers. If there is, >> > >> please >> > >> > point me to it, and we can remove the section. I don't think we >> > >> > should >> > >> be >> > >> > writing two pages at once, so I decided not to drop any essential >> > >> > information. >> > >> > >> > >> > > Components and their maintainers >> > >> > > >> > >> > > It seems that this list should be updated too. >> > >> > > >> > >> > I would be glad if somebody does it, but I don't have any more >> > >> information >> > >> > to fill there. >> > >> > >> > >> > >> > >> > > > Working on a ticket >> > >> > > I think we should mention the Intellij IDEA checkstyle plugin >> > >> > > and >> > its >> > >> > > configuration (importation of checkstyle.xml to the IDE). >> > >> > > >> > >> > I would be glad if somebody contributes to it, or we may just >> > >> > provide >> > a >> > >> > link to coding guidelines and mention it there. >> > >> > >> > >> > >> > >> > >> > >> > > > GIT workflow >
[MTCGA]: new failures in builds [5918848] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New test failure in master IgniteLocalWalSizeTest.testLocalSegmentSizesArchiveOnly https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5930176229191869682&branch=%3Cdefault%3E&tab=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 05:55:29 18-03-2021
[MTCGA]: new failures in builds [5918040] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *Test with high flaky rate in master BinaryEnumsSelfTest.testInstanceFromBytes https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-9144457051483384188&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - nikolay https://ci.ignite.apache.org/viewModification.html?modId=919548 - atri sharma https://ci.ignite.apache.org/viewModification.html?modId=919527 - zstan https://ci.ignite.apache.org/viewModification.html?modId=919397 - 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 05:10:19 18-03-2021
Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Maxim, I had to grant you admin access in the blogging settings. No you should be able to create an article and invite other members (log in with your apache ID): https://blogs.apache.org/roller-ui/authoring/members!save.rol Like the blog. (if you haven't done this yet, I'm encouraging you to work with Kseniya's technical editors who can suggest style and flow-related changes). - Denis On Wed, Mar 17, 2021 at 12:44 PM Maxim Muzafarov wrote: > Denis, > > I'm getting the following error while trying to create a new Weblog > > Sorry, the blog administrator has disabled creation of new blogs. > > By the way, Nikita, Denis > > Can you review my blog post, please? > > https://github.com/Mmuzaf/mmuzaf.github.io/blob/main/_post/Release_Newsletter_210.md > > > On Wed, 17 Mar 2021 at 19:32, Denis Magda wrote: > > > > Maxim, > > > > Check one more time. The infra instruction that you shared says a > contributor needs to be in the Admin group in JIRA to get write access to > the blog. I've added you to the Admin group. > > - > > Denis > > > > > > > > On Wed, Mar 17, 2021 at 12:00 PM Maxim Muzafarov > wrote: > >> > >> Denis, > >> > >> > >> I'd like to create a post on the blogs.apache.org news feed with the > >> 2.10 release news. Do I need additional privileges to do this? > >> > >> According to the wiki page [1] after login with my credentials, I > >> should see the `add post` button, however, I can't find it on the main > >> page. Am I missing something? > >> > >> > >> > >> [1] https://infra.apache.org/project-blogs > >> [2] https://blogs.apache.org/ignite/ > >> > >> On Wed, 17 Mar 2021 at 13:43, Pavel Tupitsyn > wrote: > >> > > >> > Maxim, > >> > > >> > I've prepared a blog post about Ignite.NET changes [1], > >> > please link it in the main post. > >> > > >> > [1] https://ptupitsyn.github.io/Whats-New-In-Ignite-Net-2.10/ > >> > > >> > On Tue, Mar 16, 2021 at 5:15 PM Maxim Muzafarov > wrote: > >> > > >> > > Denis, > >> > > > >> > > > >> > > Thank you. I'll prepare a blog post notes for the major 2.10 > features. > >> > > The release hasn't been announced yet, some artefacts still waiting > to > >> > > be published. Hope everything will be ready by the end of this week. > >> > > > >> > > > >> > > > Btw, don't we want to arrange a meetup gathering for Virtual or > >> > > Russian-speaking meetup or both? > >> > > > >> > > It depends on our goals. If we want to promote Ignite Summit 2021, > so > >> > > the English-speaking meetup makes sense. > >> > > > >> > > On Tue, 16 Mar 2021 at 16:00, Denis Magda > wrote: > >> > > > > >> > > > Hi Maxim, > >> > > > > >> > > > Ideally, a blog post should be published together with the > announcement > >> > > > email. So that the readers can learn more details from the > article. > >> > > Anyway, > >> > > > you can post it later for 2.10 as long as the release is already > >> > > completed. > >> > > > > >> > > > Btw, don't we want to arrange a meetup gathering for Virtual or > >> > > > Russian-speaking meetup, or both? > >> > > > > >> > > > - > >> > > > Denis > >> > > > > >> > > > > >> > > > On Mon, Mar 15, 2021 at 8:55 PM Maxim Muzafarov < > mmu...@apache.org> > >> > > wrote: > >> > > > > >> > > > > Folks, > >> > > > > > >> > > > > I've done almost all the release steps with publishing accepted > >> > > changes. > >> > > > > What should I do with an announcement blog post for > blogs.apache.org? > >> > > > > Should it also be prepared prior to an announcement message? > >> > > > > > >> > > > > On Thu, 11 Mar 2021 at 00:10, Maxim Muzafarov < > mmu...@apache.org> > >> > > wrote: > >> > > > > > > >> > > > > > Pavel, > >> > > > > > > >> > > > > > Thank you! I'll prepare a new rc shortly. > >> > > > > > > >> > > > > > On Wed, 10 Mar 2021 at 23:20, Pavel Tupitsyn < > ptupit...@apache.org> > >> > > > > wrote: > >> > > > > > > > >> > > > > > > Maxim, thanks! > >> > > > > > > I've cherry-picked IGNITE-14293. > >> > > > > > > > >> > > > > > > On Wed, Mar 10, 2021 at 10:05 PM Maxim Muzafarov < > >> > > mmu...@apache.org> > >> > > > > wrote: > >> > > > > > > > >> > > > > > > > Pavel, > >> > > > > > > > > >> > > > > > > > Sorry, my bad. Entangled in my local branches during > trying to > >> > > > > > > > cherry-pick related commits. > >> > > > > > > > I've reverted this change. > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > On Wed, 10 Mar 2021 at 21:58, Pavel Tupitsyn < > >> > > ptupit...@apache.org> > >> > > > > wrote: > >> > > > > > > > > > >> > > > > > > > > Maxim, > >> > > > > > > > > > >> > > > > > > > > I see that you have already cherry-picked IGNITE-13979 > - was > >> > > that > >> > > > > > > > > intentional? > >> > > > > > > > > If we keep it, let's cherry-pick 14250 as well? > >> > > > > > > > > > >> > > > > > > > > On Wed, Mar 10, 2021 at 8:21 PM Maxim Muzafarov < > >> > > mmu...@apache.org > >> > > > > > > >> > > > > > > > wrote: > >> > > > > > > > > > >> > > > > > > > > > Pavel, > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > I think it is
Re: IEP-70: Async Continuation Executor
We implemented the ContinueWith() suggestion from Pavel, and it works well
so far in testing, though we do not have data to support if there is or is
not a performance penalty in our use case..
To lend another vote to the 'Don't do continuations on the striped thread
pool' line of thinking: Deadlocking is an issue as is starvation. In some
ways starvation is more insidious because by the time things stop working
the cause and effect distance may be large.
I appreciate the documentation does make statements about not performing
cache operations in a continuation due to deadlock possibilities, but that
statement does not reveal why this is an issue. It is less a case of a
async cache operation being followed by some other cache operation (an
immediate issue), and more a general case of the continuation of
application logic using a striped pool thread in a way that might mean that
thread is never given back - it's now just a piece of the application
infrastructure until some other application activity schedules away from
that thread (eg: by ContinueWith or some other async operation in the
application code that releases the thread). To be fair, beyond structures
like ContinueWith(), it is not obvious how that continuation thread should
be handed back. This will be the same behaviour for dedicated continuation
pools, but with far less risk in the absence of ContinueWith() constructs.
In the .Net world this is becoming more of an issue as fewer .Net use cases
outside of UI bother with synchronization contexts by default.
Raymond.
On Thu, Mar 18, 2021 at 9:56 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Hi Denis,
>
> I think Pavel's main point is that behavior is unpredictable. For example,
> AFAIK, putAsync can be executed in the main thread instead of the striped
> pool thread if the operation is local. The listener can also be executed in
> the main thread - this happens if the future is completed prior to listener
> invocation (this is actually quite possible in the unit test environment
> causing the test to pass). Finally, I'm pretty sure there are many cases
> when a deadlock does not occur right away, but instead it will reveal
> itself under high load due to thread starvation. The latter type of issues
> is the most dangerous because they are often reproduced only in production.
> Finally, there are performance considerations as well - cache operations
> and listeners share the same fixed-sized pool which can have negative
> effects.
>
> I'm OK with the change. Although, it might be better to introduce a new
> fixed-sized pool instead of ForkJoinPool for listeners, simply because this
> is the approach taken throughout the project. But this is up to a debate.
>
> -Val
>
> On Wed, Mar 17, 2021 at 11:31 AM Denis Garus wrote:
>
> > Pavel,
> > I tried this:
> >
> > @Test
> > public void test() throws Exception {
> > IgniteCache cache =
> > startGrid().getOrCreateCache("test_cache");
> >
> > cache.putAsync(1, "one").listen(f -> cache.replace(1, "two"));
> >
> > assertEquals("two", cache.get(1));
> > }
> >
> > and this test is green.
> > I believe that an user can make listener that leads to deadlock, but
> > the example in the IEP does not reflect this.
> >
> >
> >
> > ср, 17 мар. 2021 г. в 17:36, Вячеслав Коптилин >:
> >
> > > Hi Pavel,
> > >
> > > > Not a good excuse really. We have a usability problem, you have to
> > admit
> > > it.
> > > Fair enough. I agree that this is a usability issue, but I have doubts
> > that
> > > the proposed approach to overcome it is the best one.
> > >
> > > > Documentation won't help - no one is going to read the Javadoc for a
> > > trivial method like putAsync
> > > That is sad... However, I don't think that this is a strong argument
> > here.
> > >
> > > This is just my opinion. Let's see what other community members have to
> > > say.
> > >
> > > Thanks,
> > > S.
> > >
> > >
> > > ср, 17 мар. 2021 г. в 17:01, Pavel Tupitsyn :
> > >
> > > > > the user should use the right API
> > > >
> > > > Not a good excuse really. We have a usability problem, you have to
> > admit
> > > > it.
> > > > "The brakes did not work on your car - too bad, you should have known
> > > that
> > > > on Sundays only your left foot is allowed on the pedal"
> > > >
> > > > This particular use case is too intricate.
> > > > Even when you know about that, it is difficult to decide what can run
> > on
> > > > the striped pool,
> > > > and what can't. It is too easy to forget.
> > > > And most people don't know, even among Ignite developers.
> > > >
> > > > Documentation won't help - no one is going to read the Javadoc for a
> > > > trivial method like putAsync.
> > > >
> > > >
> > > > So I propose to have a safe default.
> > > > Then document the performance tuning opportunity on [1].
> > > >
> > > > Think about how many users abandon a product because it mysteriously
> > > > crashes and hangs.
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://ignite.apache
Re: How to Contribute 2021
Kseniya, >From my point of view he contribute.html and CONTRIBUTING.md should be the same with the reference to the wiki page How_to_Contribute_2021 describing all the additional details and common issues with the first contributions. I also think it would be better to create special dedicated pages for committers and contributors. I don't get the idea why we can't do this keeping the same data as they were on the original How_to_Contribute page. On Tue, 16 Mar 2021 at 13:18, Kseniya Romanova wrote: > > So we do have 3 sources for how to contribute: > > 1. https://ignite.apache.org/community/contribute.html > 2. https://github.com/apache/ignite/blob/master/CONTRIBUTING.md > 3. https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute+2021 > > Seems that wiki is more technical, right? But is there any reason for 2 > different versions for GitHub and the website? > > вт, 16 мар. 2021 г. в 13:11, Ilya Kasnacheev : > > > Hello again! > > > > Based on the feedback, I have removed ASCII art from the git section, > > making it shorter and clearer. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > вт, 16 мар. 2021 г. в 11:47, Ilya Kasnacheev : > > > > > Hello, Pavel! > > > > > > At the very minimum, a newcomer should be able to run tests on TC or > > MTCGA. > > > > > > Explaining that process takes most of the contribution guide. > > > > > > Even if somebody is ready to run those tests for a newcomer once or twice > > > (already a long shot, it's hard to even get a simple review), they have > > no > > > opportunity to learn except for this guide. They really don't have > > anybody > > > to ask. > > > > > > As I have said, I can't create two documents at the same time so if we > > > need a separate one for committers, it may only be written after the > > fact, > > > and we can't remove essential information in the meantime. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > пн, 15 мар. 2021 г. в 18:26, Pavel Tupitsyn : > > > > > >> Ilya, > > >> > > >> Thanks for the effort! > > >> > > >> I think this guide should be much shorter and simple. > > >> Right now it is intimidating for newcomers. > > >> > > >> What they need is basically > > >> * Register in Jira, pick a ticket, assign, put In Progress > > >> * Create a fork, implement > > >> * Create a PR > > >> * Ask for review > > >> > > >> Maybe we should have a separate, detailed guide for Committers, > > >> and a simple one for Contributors? > > >> > > >> On Mon, Mar 15, 2021 at 6:19 PM Ilya Kasnacheev < > > >> ilya.kasnach...@gmail.com> > > >> wrote: > > >> > > >> > Hello! > > >> > > > >> > Please see inline. > > >> > > > >> > пн, 15 мар. 2021 г. в 18:06, Maxim Muzafarov : > > >> > > > >> > > Hello, > > >> > > > > >> > > > > >> > > > Ignite employs both Review-Then-Commit processes. > > >> > > > > >> > > The Commit-Then-Review (CTR) removed? > > >> > > > > >> > I don't see any applications of CTR during the few last years. > > Streamers > > >> > were supposed to be CTR but Saikat Maitra still asked for the review > > of > > >> > streamers-related commits. > > >> > > > >> > > Information for committers > > >> > > > > >> > > Do we need this on a page for newcomers? I'd like to mention that > > some > > >> > > of the committers still use the commit script, however, I think it > > >> > > will be better to configure the GitHub interaction. > > >> > > > > >> > I don't think there's a separate page for committers. If there is, > > >> please > > >> > point me to it, and we can remove the section. I don't think we should > > >> be > > >> > writing two pages at once, so I decided not to drop any essential > > >> > information. > > >> > > > >> > > Components and their maintainers > > >> > > > > >> > > It seems that this list should be updated too. > > >> > > > > >> > I would be glad if somebody does it, but I don't have any more > > >> information > > >> > to fill there. > > >> > > > >> > > > >> > > > Working on a ticket > > >> > > I think we should mention the Intellij IDEA checkstyle plugin and > > its > > >> > > configuration (importation of checkstyle.xml to the IDE). > > >> > > > > >> > I would be glad if somebody contributes to it, or we may just provide > > a > > >> > link to coding guidelines and mention it there. > > >> > > > >> > > > >> > > > >> > > > GIT workflow > > >> > > > > >> > > Do we need it? > > >> > > > > >> > I think we do, this workflow is non-trivial and I don't think it is > > >> > documented anywhere. We can get rid of ASCII art section, though. > > >> > > > >> > WDYT? > > >> > > > >> > Regards, > > >> > > > >> > > > >> > > > > >> > > > > >> > > On Mon, 15 Mar 2021 at 17:25, Ilya Kasnacheev < > > >> ilya.kasnach...@gmail.com > > >> > > > > >> > > wrote: > > >> > > > > > >> > > > Hello! > > >> > > > > > >> > > > When adding new users to the Contributor role, we usually give > > them > > >> a > > >> > > link > > >> > > > to "How to Contribute" wiki page. > > >> > > > > > >> > > > However, I was feeling that it wa
Re: IGNITE-2399 : Asynchronous Acquire method in IgniteSemaphore
Hi Atri, Looks good to me, I've merged the changes. Please resolve the ticket. -Val On Wed, Mar 17, 2021 at 5:07 AM Atri Sharma wrote: > Hi Valentine, > > Hoping you are well. > > Please let me know if the PR looks ok. > > Regards, > > Atri > > > On Thu, 11 Mar 2021, 12:09 Atri Sharma, wrote: > > > Hi Val, > > > > Thanks for taking a look. I have updated the PR, please see and let me > > know your thoughts and feedback. > > > > Regards, > > > > Atri > > > > On Thu, Mar 11, 2021 at 6:16 AM Valentin Kulichenko > > wrote: > > > > > > Atri, > > > > > > I've added my comments to the PR. > > > > > > -Val > > > > > > On Wed, Mar 10, 2021 at 2:44 AM Atri Sharma wrote: > > > > > > > I have just updated the PR: > > > > > > > > https://github.com/apache/ignite/pull/8820 > > > > > > > > Please review. > > > > > > > > On Wed, Mar 10, 2021 at 1:51 PM Atri Sharma wrote: > > > > > > > > > > Hi Val, > > > > > > > > > > Thank you for taking the time on this one. > > > > > > > > > > The main reason as to why I chose that signature was because I felt > > it > > > > > gave a clear idea of the interface that the user should expect when > > > > > using the method. So essentially, the user is providing a callback > > > > > listener himself/herself and the API is just using that to tie the > > > > > lifecycle of holding the semaphore. > > > > > > > > > > However, I do see your point and feel that the current signature > that > > > > > the PR has will limit the usability of the method and make users > jump > > > > > through more hoops. I have changed the signature to accept Callable > > > > > returning T. > > > > > > > > > > Regards, > > > > > > > > > > Atri > > > > > > > > > > On Wed, Mar 10, 2021 at 5:29 AM Valentin Kulichenko > > > > > wrote: > > > > > > > > > > > > Hi Atri, > > > > > > > > > > > > First and foremost, we need to clarify the API for this > > functionality. > > > > > > There are two options presented in the ticket, but no clear > > decision > > > > about > > > > > > which one should be used. I personally think that the original > > > > signature > > > > > > (the one in the ticket description) makes more sense, but it > looks > > like > > > > > > you've implemented an alternative suggested in the comments. What > > was > > > > your > > > > > > motivation behind that? > > > > > > > > > > > > As for where the method can be located, I'm OK if we add it > > directly > > > > to the > > > > > > IgniteSemaphore interface. > > > > > > > > > > > > -Val > > > > > > > > > > > > On Tue, Mar 9, 2021 at 8:22 AM Atri Sharma > > wrote: > > > > > > > > > > > > > Gentle ping > > > > > > > > > > > > > > On Mon, 8 Mar 2021, 13:51 Atri Sharma, > wrote: > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > I would like to start a discussion around IGNITE-2399. > > > > > > > > > > > > > > > > Background: The typical use of IgniteSemaphore consists of > > > > acquiring > > > > > > > > the semaphore, performing the task and releasing the > semaphore. > > > > This > > > > > > > > JIRA proposes a new method which will accept a callable, > > acquire > > > > the > > > > > > > > semaphore, and return a future. Upon completion of the > future, > > the > > > > > > > > semaphore is released. > > > > > > > > > > > > > > > > This API seems useful for an easy encapsulation of the > > described > > > > use > > > > > > > > case and does not cause an internal flux since all the > changes > > are > > > > > > > > focused at the public API. > > > > > > > > > > > > > > > > WIP PR for the same: > > > > > > > > > > > > > > > > https://github.com/apache/ignite/pull/8820 > > > > > > > > > > > > > > > > Please share your thoughts and comments. > > > > > > > > > > > > > > > > -- > > > > > > > > Regards, > > > > > > > > > > > > > > > > Atri > > > > > > > > Apache Concerted > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Regards, > > > > > > > > > > Atri > > > > > Apache Concerted > > > > > > > > > > > > > > > > -- > > > > Regards, > > > > > > > > Atri > > > > Apache Concerted > > > > > > > > -- > > Regards, > > > > Atri > > Apache Concerted > > >
Re: IEP-70: Async Continuation Executor
Hi Denis,
I think Pavel's main point is that behavior is unpredictable. For example,
AFAIK, putAsync can be executed in the main thread instead of the striped
pool thread if the operation is local. The listener can also be executed in
the main thread - this happens if the future is completed prior to listener
invocation (this is actually quite possible in the unit test environment
causing the test to pass). Finally, I'm pretty sure there are many cases
when a deadlock does not occur right away, but instead it will reveal
itself under high load due to thread starvation. The latter type of issues
is the most dangerous because they are often reproduced only in production.
Finally, there are performance considerations as well - cache operations
and listeners share the same fixed-sized pool which can have negative
effects.
I'm OK with the change. Although, it might be better to introduce a new
fixed-sized pool instead of ForkJoinPool for listeners, simply because this
is the approach taken throughout the project. But this is up to a debate.
-Val
On Wed, Mar 17, 2021 at 11:31 AM Denis Garus wrote:
> Pavel,
> I tried this:
>
> @Test
> public void test() throws Exception {
> IgniteCache cache =
> startGrid().getOrCreateCache("test_cache");
>
> cache.putAsync(1, "one").listen(f -> cache.replace(1, "two"));
>
> assertEquals("two", cache.get(1));
> }
>
> and this test is green.
> I believe that an user can make listener that leads to deadlock, but
> the example in the IEP does not reflect this.
>
>
>
> ср, 17 мар. 2021 г. в 17:36, Вячеслав Коптилин :
>
> > Hi Pavel,
> >
> > > Not a good excuse really. We have a usability problem, you have to
> admit
> > it.
> > Fair enough. I agree that this is a usability issue, but I have doubts
> that
> > the proposed approach to overcome it is the best one.
> >
> > > Documentation won't help - no one is going to read the Javadoc for a
> > trivial method like putAsync
> > That is sad... However, I don't think that this is a strong argument
> here.
> >
> > This is just my opinion. Let's see what other community members have to
> > say.
> >
> > Thanks,
> > S.
> >
> >
> > ср, 17 мар. 2021 г. в 17:01, Pavel Tupitsyn :
> >
> > > > the user should use the right API
> > >
> > > Not a good excuse really. We have a usability problem, you have to
> admit
> > > it.
> > > "The brakes did not work on your car - too bad, you should have known
> > that
> > > on Sundays only your left foot is allowed on the pedal"
> > >
> > > This particular use case is too intricate.
> > > Even when you know about that, it is difficult to decide what can run
> on
> > > the striped pool,
> > > and what can't. It is too easy to forget.
> > > And most people don't know, even among Ignite developers.
> > >
> > > Documentation won't help - no one is going to read the Javadoc for a
> > > trivial method like putAsync.
> > >
> > >
> > > So I propose to have a safe default.
> > > Then document the performance tuning opportunity on [1].
> > >
> > > Think about how many users abandon a product because it mysteriously
> > > crashes and hangs.
> > >
> > > [1]
> > >
> > >
> >
> https://ignite.apache.org/docs/latest/perf-and-troubleshooting/general-perf-tips
> > >
> > >
> > > On Wed, Mar 17, 2021 at 4:21 PM Вячеслав Коптилин <
> > > slava.kopti...@gmail.com>
> > > wrote:
> > >
> > > > Hi Pavel,
> > > >
> > > > Well, I think that the user should use the right API instead of
> > > introducing
> > > > uncontested overhead for everyone.
> > > > For instance, the code that is provided by IEP can changed as
> follows:
> > > >
> > > > IgniteFuture fut = cache.putAsync(1, 1);
> > > > fut.listenAync(f -> {
> > > > // Executes on Striped pool and deadlocks.
> > > > cache.replace(1, 2);
> > > > }, ForkJoinPool.commonPool());
> > > >
> > > > Of course, it does not mean that this fact should not be properly
> > > > documented.
> > > > Perhaps, I am missing something.
> > > >
> > > > Thanks,
> > > > S.
> > > >
> > > > ср, 17 мар. 2021 г. в 16:01, Pavel Tupitsyn :
> > > >
> > > > > Slava,
> > > > >
> > > > > Your suggestion is to keep things as is and discard the IEP, right?
> > > > >
> > > > > > this can lead to significant overhead
> > > > > Yes, there is some overhead, but the cost of accidentally starving
> > the
> > > > > striped pool is worse,
> > > > > not to mention the deadlocks.
> > > > >
> > > > > I believe that we should favor correctness over performance in any
> > > case.
> > > > >
> > > > >
> > > > > On Wed, Mar 17, 2021 at 3:34 PM Вячеслав Коптилин <
> > > > > slava.kopti...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Well, the specified method already exists :)
> > > > > >
> > > > > > /**
> > > > > > * Registers listener closure to be asynchronously notified
> > > > whenever
> > > > > > future completes.
> > > > > > * Closure will be processed in specified executor.
> > > > > > *
> > > > > > * @param lsnr Listener closure to register. Cannot be {@code
> > > > null}.
>
[jira] [Created] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
Mikhail Petrov created IGNITE-14335: --- Summary: Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity Key: IGNITE-14335 URL: https://issues.apache.org/jira/browse/IGNITE-14335 Project: Ignite Issue Type: Improvement Reporter: Mikhail Petrov Assignee: Mikhail Petrov It's proposed to: 1. Make an IgniteAuthenticationProcessor implement GridSecurityProcessor interface. 2. Remove duplication of security checks and leave IgniteSecurity as a single security API. 3. Remove the AuthorizationContext completely as IgniteSecurity provides an API for storing and managing the security contexts. 4. Extend GridSecurityPlugin interface with methods that provide ability to manage security users to support existing commands available for authentication processor - alter/drop/create through SQL and REST. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: IEP-70: Async Continuation Executor
Pavel,
I tried this:
@Test
public void test() throws Exception {
IgniteCache cache =
startGrid().getOrCreateCache("test_cache");
cache.putAsync(1, "one").listen(f -> cache.replace(1, "two"));
assertEquals("two", cache.get(1));
}
and this test is green.
I believe that an user can make listener that leads to deadlock, but
the example in the IEP does not reflect this.
ср, 17 мар. 2021 г. в 17:36, Вячеслав Коптилин :
> Hi Pavel,
>
> > Not a good excuse really. We have a usability problem, you have to admit
> it.
> Fair enough. I agree that this is a usability issue, but I have doubts that
> the proposed approach to overcome it is the best one.
>
> > Documentation won't help - no one is going to read the Javadoc for a
> trivial method like putAsync
> That is sad... However, I don't think that this is a strong argument here.
>
> This is just my opinion. Let's see what other community members have to
> say.
>
> Thanks,
> S.
>
>
> ср, 17 мар. 2021 г. в 17:01, Pavel Tupitsyn :
>
> > > the user should use the right API
> >
> > Not a good excuse really. We have a usability problem, you have to admit
> > it.
> > "The brakes did not work on your car - too bad, you should have known
> that
> > on Sundays only your left foot is allowed on the pedal"
> >
> > This particular use case is too intricate.
> > Even when you know about that, it is difficult to decide what can run on
> > the striped pool,
> > and what can't. It is too easy to forget.
> > And most people don't know, even among Ignite developers.
> >
> > Documentation won't help - no one is going to read the Javadoc for a
> > trivial method like putAsync.
> >
> >
> > So I propose to have a safe default.
> > Then document the performance tuning opportunity on [1].
> >
> > Think about how many users abandon a product because it mysteriously
> > crashes and hangs.
> >
> > [1]
> >
> >
> https://ignite.apache.org/docs/latest/perf-and-troubleshooting/general-perf-tips
> >
> >
> > On Wed, Mar 17, 2021 at 4:21 PM Вячеслав Коптилин <
> > slava.kopti...@gmail.com>
> > wrote:
> >
> > > Hi Pavel,
> > >
> > > Well, I think that the user should use the right API instead of
> > introducing
> > > uncontested overhead for everyone.
> > > For instance, the code that is provided by IEP can changed as follows:
> > >
> > > IgniteFuture fut = cache.putAsync(1, 1);
> > > fut.listenAync(f -> {
> > > // Executes on Striped pool and deadlocks.
> > > cache.replace(1, 2);
> > > }, ForkJoinPool.commonPool());
> > >
> > > Of course, it does not mean that this fact should not be properly
> > > documented.
> > > Perhaps, I am missing something.
> > >
> > > Thanks,
> > > S.
> > >
> > > ср, 17 мар. 2021 г. в 16:01, Pavel Tupitsyn :
> > >
> > > > Slava,
> > > >
> > > > Your suggestion is to keep things as is and discard the IEP, right?
> > > >
> > > > > this can lead to significant overhead
> > > > Yes, there is some overhead, but the cost of accidentally starving
> the
> > > > striped pool is worse,
> > > > not to mention the deadlocks.
> > > >
> > > > I believe that we should favor correctness over performance in any
> > case.
> > > >
> > > >
> > > > On Wed, Mar 17, 2021 at 3:34 PM Вячеслав Коптилин <
> > > > slava.kopti...@gmail.com>
> > > > wrote:
> > > >
> > > > > Well, the specified method already exists :)
> > > > >
> > > > > /**
> > > > > * Registers listener closure to be asynchronously notified
> > > whenever
> > > > > future completes.
> > > > > * Closure will be processed in specified executor.
> > > > > *
> > > > > * @param lsnr Listener closure to register. Cannot be {@code
> > > null}.
> > > > > * @param exec Executor to run listener. Cannot be {@code
> null}.
> > > > > */
> > > > > public void listenAsync(IgniteInClosure IgniteFuture>
> > > > lsnr,
> > > > > Executor exec);
> > > > >
> > > > > Thanks,
> > > > > S.
> > > > >
> > > > > ср, 17 мар. 2021 г. в 15:25, Вячеслав Коптилин <
> > > slava.kopti...@gmail.com
> > > > >:
> > > > >
> > > > > > Hello Pavel,
> > > > > >
> > > > > > I took a look at your IEP and pool request. I have the following
> > > > > concerns.
> > > > > > First of all, this change breaks the contract of
> > > > > IgniteFuture#listen(lsnr)
> > > > > >
> > > > > > /**
> > > > > > * Registers listener closure to be asynchronously notified
> > > > whenever
> > > > > > future completes.
> > > > > > * Closure will be processed in thread that completes this
> > future
> > > > or
> > > > > > (if future already
> > > > > > * completed) immediately in current thread.
> > > > > > *
> > > > > > * @param lsnr Listener closure to register. Cannot be {@code
> > > > null}.
> > > > > > */
> > > > > > public void listen(IgniteInClosure>
> > > lsnr);
> > > > > >
> > > > > > In your pull request, the listener is always called from a
> > > > specified
> > > > > > thread pool (which is fork-join by default)
> > > > > > even though the future is already completed at the mome
Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Denis, I'm getting the following error while trying to create a new Weblog > Sorry, the blog administrator has disabled creation of new blogs. By the way, Nikita, Denis Can you review my blog post, please? https://github.com/Mmuzaf/mmuzaf.github.io/blob/main/_post/Release_Newsletter_210.md On Wed, 17 Mar 2021 at 19:32, Denis Magda wrote: > > Maxim, > > Check one more time. The infra instruction that you shared says a contributor > needs to be in the Admin group in JIRA to get write access to the blog. I've > added you to the Admin group. > - > Denis > > > > On Wed, Mar 17, 2021 at 12:00 PM Maxim Muzafarov wrote: >> >> Denis, >> >> >> I'd like to create a post on the blogs.apache.org news feed with the >> 2.10 release news. Do I need additional privileges to do this? >> >> According to the wiki page [1] after login with my credentials, I >> should see the `add post` button, however, I can't find it on the main >> page. Am I missing something? >> >> >> >> [1] https://infra.apache.org/project-blogs >> [2] https://blogs.apache.org/ignite/ >> >> On Wed, 17 Mar 2021 at 13:43, Pavel Tupitsyn wrote: >> > >> > Maxim, >> > >> > I've prepared a blog post about Ignite.NET changes [1], >> > please link it in the main post. >> > >> > [1] https://ptupitsyn.github.io/Whats-New-In-Ignite-Net-2.10/ >> > >> > On Tue, Mar 16, 2021 at 5:15 PM Maxim Muzafarov wrote: >> > >> > > Denis, >> > > >> > > >> > > Thank you. I'll prepare a blog post notes for the major 2.10 features. >> > > The release hasn't been announced yet, some artefacts still waiting to >> > > be published. Hope everything will be ready by the end of this week. >> > > >> > > >> > > > Btw, don't we want to arrange a meetup gathering for Virtual or >> > > Russian-speaking meetup or both? >> > > >> > > It depends on our goals. If we want to promote Ignite Summit 2021, so >> > > the English-speaking meetup makes sense. >> > > >> > > On Tue, 16 Mar 2021 at 16:00, Denis Magda wrote: >> > > > >> > > > Hi Maxim, >> > > > >> > > > Ideally, a blog post should be published together with the announcement >> > > > email. So that the readers can learn more details from the article. >> > > Anyway, >> > > > you can post it later for 2.10 as long as the release is already >> > > completed. >> > > > >> > > > Btw, don't we want to arrange a meetup gathering for Virtual or >> > > > Russian-speaking meetup, or both? >> > > > >> > > > - >> > > > Denis >> > > > >> > > > >> > > > On Mon, Mar 15, 2021 at 8:55 PM Maxim Muzafarov >> > > wrote: >> > > > >> > > > > Folks, >> > > > > >> > > > > I've done almost all the release steps with publishing accepted >> > > changes. >> > > > > What should I do with an announcement blog post for blogs.apache.org? >> > > > > Should it also be prepared prior to an announcement message? >> > > > > >> > > > > On Thu, 11 Mar 2021 at 00:10, Maxim Muzafarov >> > > wrote: >> > > > > > >> > > > > > Pavel, >> > > > > > >> > > > > > Thank you! I'll prepare a new rc shortly. >> > > > > > >> > > > > > On Wed, 10 Mar 2021 at 23:20, Pavel Tupitsyn >> > > > > wrote: >> > > > > > > >> > > > > > > Maxim, thanks! >> > > > > > > I've cherry-picked IGNITE-14293. >> > > > > > > >> > > > > > > On Wed, Mar 10, 2021 at 10:05 PM Maxim Muzafarov < >> > > mmu...@apache.org> >> > > > > wrote: >> > > > > > > >> > > > > > > > Pavel, >> > > > > > > > >> > > > > > > > Sorry, my bad. Entangled in my local branches during trying to >> > > > > > > > cherry-pick related commits. >> > > > > > > > I've reverted this change. >> > > > > > > > >> > > > > > > > >> > > > > > > > On Wed, 10 Mar 2021 at 21:58, Pavel Tupitsyn < >> > > ptupit...@apache.org> >> > > > > wrote: >> > > > > > > > > >> > > > > > > > > Maxim, >> > > > > > > > > >> > > > > > > > > I see that you have already cherry-picked IGNITE-13979 - was >> > > that >> > > > > > > > > intentional? >> > > > > > > > > If we keep it, let's cherry-pick 14250 as well? >> > > > > > > > > >> > > > > > > > > On Wed, Mar 10, 2021 at 8:21 PM Maxim Muzafarov < >> > > mmu...@apache.org >> > > > > > >> > > > > > > > wrote: >> > > > > > > > > >> > > > > > > > > > Pavel, >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > I think it is better and safe to cherry-pick the >> > > `IGNITE-14293 >> > > > > .NET: >> > > > > > > > > > AffinityKey does not work` only. I will be very happy to >> > > accept >> > > > > your >> > > > > > > > > > help with it. >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > The IGNITE-13979 (.NET: Modernize examples) is very big and >> > > has >> > > > > some >> > > > > > > > > > related issues too (most of them are fixed), so I think it >> > > > > > > > > > is >> > > > > better >> > > > > > > > > > here to postpone it to the next release and give it a bit >> > > > > > > > > > of >> > > > > time for >> > > > > > > > > > the self-stabilization process :-) >> > > > > > > > > > >> > > > > > > > > > On Wed, 10 Mar 2021 at 20:17, Pavel Tupitsyn < >> > > > > ptupit...@apache.org> >> > > > > > > >
Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Maxim, Check one more time. The infra instruction that you shared says a contributor needs to be in the Admin group in JIRA to get write access to the blog. I've added you to the Admin group. - Denis On Wed, Mar 17, 2021 at 12:00 PM Maxim Muzafarov wrote: > Denis, > > > I'd like to create a post on the blogs.apache.org news feed with the > 2.10 release news. Do I need additional privileges to do this? > > According to the wiki page [1] after login with my credentials, I > should see the `add post` button, however, I can't find it on the main > page. Am I missing something? > > > > [1] https://infra.apache.org/project-blogs > [2] https://blogs.apache.org/ignite/ > > On Wed, 17 Mar 2021 at 13:43, Pavel Tupitsyn wrote: > > > > Maxim, > > > > I've prepared a blog post about Ignite.NET changes [1], > > please link it in the main post. > > > > [1] https://ptupitsyn.github.io/Whats-New-In-Ignite-Net-2.10/ > > > > On Tue, Mar 16, 2021 at 5:15 PM Maxim Muzafarov > wrote: > > > > > Denis, > > > > > > > > > Thank you. I'll prepare a blog post notes for the major 2.10 features. > > > The release hasn't been announced yet, some artefacts still waiting to > > > be published. Hope everything will be ready by the end of this week. > > > > > > > > > > Btw, don't we want to arrange a meetup gathering for Virtual or > > > Russian-speaking meetup or both? > > > > > > It depends on our goals. If we want to promote Ignite Summit 2021, so > > > the English-speaking meetup makes sense. > > > > > > On Tue, 16 Mar 2021 at 16:00, Denis Magda wrote: > > > > > > > > Hi Maxim, > > > > > > > > Ideally, a blog post should be published together with the > announcement > > > > email. So that the readers can learn more details from the article. > > > Anyway, > > > > you can post it later for 2.10 as long as the release is already > > > completed. > > > > > > > > Btw, don't we want to arrange a meetup gathering for Virtual or > > > > Russian-speaking meetup, or both? > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Mon, Mar 15, 2021 at 8:55 PM Maxim Muzafarov > > > wrote: > > > > > > > > > Folks, > > > > > > > > > > I've done almost all the release steps with publishing accepted > > > changes. > > > > > What should I do with an announcement blog post for > blogs.apache.org? > > > > > Should it also be prepared prior to an announcement message? > > > > > > > > > > On Thu, 11 Mar 2021 at 00:10, Maxim Muzafarov > > > wrote: > > > > > > > > > > > > Pavel, > > > > > > > > > > > > Thank you! I'll prepare a new rc shortly. > > > > > > > > > > > > On Wed, 10 Mar 2021 at 23:20, Pavel Tupitsyn < > ptupit...@apache.org> > > > > > wrote: > > > > > > > > > > > > > > Maxim, thanks! > > > > > > > I've cherry-picked IGNITE-14293. > > > > > > > > > > > > > > On Wed, Mar 10, 2021 at 10:05 PM Maxim Muzafarov < > > > mmu...@apache.org> > > > > > wrote: > > > > > > > > > > > > > > > Pavel, > > > > > > > > > > > > > > > > Sorry, my bad. Entangled in my local branches during trying > to > > > > > > > > cherry-pick related commits. > > > > > > > > I've reverted this change. > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 10 Mar 2021 at 21:58, Pavel Tupitsyn < > > > ptupit...@apache.org> > > > > > wrote: > > > > > > > > > > > > > > > > > > Maxim, > > > > > > > > > > > > > > > > > > I see that you have already cherry-picked IGNITE-13979 - > was > > > that > > > > > > > > > intentional? > > > > > > > > > If we keep it, let's cherry-pick 14250 as well? > > > > > > > > > > > > > > > > > > On Wed, Mar 10, 2021 at 8:21 PM Maxim Muzafarov < > > > mmu...@apache.org > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Pavel, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think it is better and safe to cherry-pick the > > > `IGNITE-14293 > > > > > .NET: > > > > > > > > > > AffinityKey does not work` only. I will be very happy to > > > accept > > > > > your > > > > > > > > > > help with it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The IGNITE-13979 (.NET: Modernize examples) is very big > and > > > has > > > > > some > > > > > > > > > > related issues too (most of them are fixed), so I think > it is > > > > > better > > > > > > > > > > here to postpone it to the next release and give it a > bit of > > > > > time for > > > > > > > > > > the self-stabilization process :-) > > > > > > > > > > > > > > > > > > > > On Wed, 10 Mar 2021 at 20:17, Pavel Tupitsyn < > > > > > ptupit...@apache.org> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Maxim, > > > > > > > > > > > > > > > > > > > > > > Sure, I can assist with cherry-picks. > > > > > > > > > > > > > > > > > > > > > > 13661 is fixed by 13979, as indicated by the "fixed by" > > > link > > > > > in Jira > > > > > > > > and > > > > > > > > > > a comment. > > > > > > > > > > > > > > > > > > > > > > IGNITE-14293 .NET: AffinityKey does not work is quite > an > > > > > unpleasant > > > > > > > > > > regression, > > > > > > > > > > > I thi
[jira] [Created] (IGNITE-14334) .NET: Thin client don't support ICollection parameters
Nikolay Izhikov created IGNITE-14334: Summary: .NET: Thin client don't support ICollection parameters Key: IGNITE-14334 URL: https://issues.apache.org/jira/browse/IGNITE-14334 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Currently, we can't call .Net -> Java with ICollection parameters. Need to fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Denis, I'd like to create a post on the blogs.apache.org news feed with the 2.10 release news. Do I need additional privileges to do this? According to the wiki page [1] after login with my credentials, I should see the `add post` button, however, I can't find it on the main page. Am I missing something? [1] https://infra.apache.org/project-blogs [2] https://blogs.apache.org/ignite/ On Wed, 17 Mar 2021 at 13:43, Pavel Tupitsyn wrote: > > Maxim, > > I've prepared a blog post about Ignite.NET changes [1], > please link it in the main post. > > [1] https://ptupitsyn.github.io/Whats-New-In-Ignite-Net-2.10/ > > On Tue, Mar 16, 2021 at 5:15 PM Maxim Muzafarov wrote: > > > Denis, > > > > > > Thank you. I'll prepare a blog post notes for the major 2.10 features. > > The release hasn't been announced yet, some artefacts still waiting to > > be published. Hope everything will be ready by the end of this week. > > > > > > > Btw, don't we want to arrange a meetup gathering for Virtual or > > Russian-speaking meetup or both? > > > > It depends on our goals. If we want to promote Ignite Summit 2021, so > > the English-speaking meetup makes sense. > > > > On Tue, 16 Mar 2021 at 16:00, Denis Magda wrote: > > > > > > Hi Maxim, > > > > > > Ideally, a blog post should be published together with the announcement > > > email. So that the readers can learn more details from the article. > > Anyway, > > > you can post it later for 2.10 as long as the release is already > > completed. > > > > > > Btw, don't we want to arrange a meetup gathering for Virtual or > > > Russian-speaking meetup, or both? > > > > > > - > > > Denis > > > > > > > > > On Mon, Mar 15, 2021 at 8:55 PM Maxim Muzafarov > > wrote: > > > > > > > Folks, > > > > > > > > I've done almost all the release steps with publishing accepted > > changes. > > > > What should I do with an announcement blog post for blogs.apache.org? > > > > Should it also be prepared prior to an announcement message? > > > > > > > > On Thu, 11 Mar 2021 at 00:10, Maxim Muzafarov > > wrote: > > > > > > > > > > Pavel, > > > > > > > > > > Thank you! I'll prepare a new rc shortly. > > > > > > > > > > On Wed, 10 Mar 2021 at 23:20, Pavel Tupitsyn > > > > wrote: > > > > > > > > > > > > Maxim, thanks! > > > > > > I've cherry-picked IGNITE-14293. > > > > > > > > > > > > On Wed, Mar 10, 2021 at 10:05 PM Maxim Muzafarov < > > mmu...@apache.org> > > > > wrote: > > > > > > > > > > > > > Pavel, > > > > > > > > > > > > > > Sorry, my bad. Entangled in my local branches during trying to > > > > > > > cherry-pick related commits. > > > > > > > I've reverted this change. > > > > > > > > > > > > > > > > > > > > > On Wed, 10 Mar 2021 at 21:58, Pavel Tupitsyn < > > ptupit...@apache.org> > > > > wrote: > > > > > > > > > > > > > > > > Maxim, > > > > > > > > > > > > > > > > I see that you have already cherry-picked IGNITE-13979 - was > > that > > > > > > > > intentional? > > > > > > > > If we keep it, let's cherry-pick 14250 as well? > > > > > > > > > > > > > > > > On Wed, Mar 10, 2021 at 8:21 PM Maxim Muzafarov < > > mmu...@apache.org > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Pavel, > > > > > > > > > > > > > > > > > > > > > > > > > > > I think it is better and safe to cherry-pick the > > `IGNITE-14293 > > > > .NET: > > > > > > > > > AffinityKey does not work` only. I will be very happy to > > accept > > > > your > > > > > > > > > help with it. > > > > > > > > > > > > > > > > > > > > > > > > > > > The IGNITE-13979 (.NET: Modernize examples) is very big and > > has > > > > some > > > > > > > > > related issues too (most of them are fixed), so I think it is > > > > better > > > > > > > > > here to postpone it to the next release and give it a bit of > > > > time for > > > > > > > > > the self-stabilization process :-) > > > > > > > > > > > > > > > > > > On Wed, 10 Mar 2021 at 20:17, Pavel Tupitsyn < > > > > ptupit...@apache.org> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Maxim, > > > > > > > > > > > > > > > > > > > > Sure, I can assist with cherry-picks. > > > > > > > > > > > > > > > > > > > > 13661 is fixed by 13979, as indicated by the "fixed by" > > link > > > > in Jira > > > > > > > and > > > > > > > > > a comment. > > > > > > > > > > > > > > > > > > > > IGNITE-14293 .NET: AffinityKey does not work is quite an > > > > unpleasant > > > > > > > > > regression, > > > > > > > > > > I think we should include it in the release. It CAN be > > included > > > > > > > without > > > > > > > > > 14250 and 13979. > > > > > > > > > > > > > > > > > > > > 14250 does not make sense without 13979. > > > > > > > > > > > > > > > > > > > > Ultimately, the question is - do we want to include 13979 > > > > (.NET: > > > > > > > > > Modernize examples), > > > > > > > > > > or not. Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 10, 2021 at 7:45 PM Maxim Muzafarov < > > > > mmu...@apache.org> > > > > > > > > > wrote: > > > > > > > > > >> > > > > > > > >
[jira] [Created] (IGNITE-14333) Zookeeper uses kill -1
Anton Vinogradov created IGNITE-14333: - Summary: Zookeeper uses kill -1 Key: IGNITE-14333 URL: https://issues.apache.org/jira/browse/IGNITE-14333 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: IEP-70: Async Continuation Executor
Hi Pavel,
> Not a good excuse really. We have a usability problem, you have to admit
it.
Fair enough. I agree that this is a usability issue, but I have doubts that
the proposed approach to overcome it is the best one.
> Documentation won't help - no one is going to read the Javadoc for a
trivial method like putAsync
That is sad... However, I don't think that this is a strong argument here.
This is just my opinion. Let's see what other community members have to say.
Thanks,
S.
ср, 17 мар. 2021 г. в 17:01, Pavel Tupitsyn :
> > the user should use the right API
>
> Not a good excuse really. We have a usability problem, you have to admit
> it.
> "The brakes did not work on your car - too bad, you should have known that
> on Sundays only your left foot is allowed on the pedal"
>
> This particular use case is too intricate.
> Even when you know about that, it is difficult to decide what can run on
> the striped pool,
> and what can't. It is too easy to forget.
> And most people don't know, even among Ignite developers.
>
> Documentation won't help - no one is going to read the Javadoc for a
> trivial method like putAsync.
>
>
> So I propose to have a safe default.
> Then document the performance tuning opportunity on [1].
>
> Think about how many users abandon a product because it mysteriously
> crashes and hangs.
>
> [1]
>
> https://ignite.apache.org/docs/latest/perf-and-troubleshooting/general-perf-tips
>
>
> On Wed, Mar 17, 2021 at 4:21 PM Вячеслав Коптилин <
> slava.kopti...@gmail.com>
> wrote:
>
> > Hi Pavel,
> >
> > Well, I think that the user should use the right API instead of
> introducing
> > uncontested overhead for everyone.
> > For instance, the code that is provided by IEP can changed as follows:
> >
> > IgniteFuture fut = cache.putAsync(1, 1);
> > fut.listenAync(f -> {
> > // Executes on Striped pool and deadlocks.
> > cache.replace(1, 2);
> > }, ForkJoinPool.commonPool());
> >
> > Of course, it does not mean that this fact should not be properly
> > documented.
> > Perhaps, I am missing something.
> >
> > Thanks,
> > S.
> >
> > ср, 17 мар. 2021 г. в 16:01, Pavel Tupitsyn :
> >
> > > Slava,
> > >
> > > Your suggestion is to keep things as is and discard the IEP, right?
> > >
> > > > this can lead to significant overhead
> > > Yes, there is some overhead, but the cost of accidentally starving the
> > > striped pool is worse,
> > > not to mention the deadlocks.
> > >
> > > I believe that we should favor correctness over performance in any
> case.
> > >
> > >
> > > On Wed, Mar 17, 2021 at 3:34 PM Вячеслав Коптилин <
> > > slava.kopti...@gmail.com>
> > > wrote:
> > >
> > > > Well, the specified method already exists :)
> > > >
> > > > /**
> > > > * Registers listener closure to be asynchronously notified
> > whenever
> > > > future completes.
> > > > * Closure will be processed in specified executor.
> > > > *
> > > > * @param lsnr Listener closure to register. Cannot be {@code
> > null}.
> > > > * @param exec Executor to run listener. Cannot be {@code null}.
> > > > */
> > > > public void listenAsync(IgniteInClosure>
> > > lsnr,
> > > > Executor exec);
> > > >
> > > > Thanks,
> > > > S.
> > > >
> > > > ср, 17 мар. 2021 г. в 15:25, Вячеслав Коптилин <
> > slava.kopti...@gmail.com
> > > >:
> > > >
> > > > > Hello Pavel,
> > > > >
> > > > > I took a look at your IEP and pool request. I have the following
> > > > concerns.
> > > > > First of all, this change breaks the contract of
> > > > IgniteFuture#listen(lsnr)
> > > > >
> > > > > /**
> > > > > * Registers listener closure to be asynchronously notified
> > > whenever
> > > > > future completes.
> > > > > * Closure will be processed in thread that completes this
> future
> > > or
> > > > > (if future already
> > > > > * completed) immediately in current thread.
> > > > > *
> > > > > * @param lsnr Listener closure to register. Cannot be {@code
> > > null}.
> > > > > */
> > > > > public void listen(IgniteInClosure>
> > lsnr);
> > > > >
> > > > > In your pull request, the listener is always called from a
> > > specified
> > > > > thread pool (which is fork-join by default)
> > > > > even though the future is already completed at the moment the
> > > listen
> > > > > method is called.
> > > > > In my opinion, this can lead to significant overhead -
> submission
> > > > > requires acquiring a lock and notifying a pool thread.
> > > > >
> > > > > It seems to me, that we should not change the current behavior.
> > > > > However, thread pool executor can be added as an optional parameter
> > of
> > > > > listen() method as follows:
> > > > >
> > > > > public void listen(IgniteInClosure>
> > > lsnr,
> > > > > Executor exec);
> > > > >
> > > > > Thanks,
> > > > > S.
> > > > >
> > > > > пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn >:
> > > > >
> > > > >> Igniters,
> > > > >>
> > > > >> Please review the IEP [1] and let me know your thoughts.
> > >
Re: IEP-70: Async Continuation Executor
> the user should use the right API
Not a good excuse really. We have a usability problem, you have to admit it.
"The brakes did not work on your car - too bad, you should have known that
on Sundays only your left foot is allowed on the pedal"
This particular use case is too intricate.
Even when you know about that, it is difficult to decide what can run on
the striped pool,
and what can't. It is too easy to forget.
And most people don't know, even among Ignite developers.
Documentation won't help - no one is going to read the Javadoc for a
trivial method like putAsync.
So I propose to have a safe default.
Then document the performance tuning opportunity on [1].
Think about how many users abandon a product because it mysteriously
crashes and hangs.
[1]
https://ignite.apache.org/docs/latest/perf-and-troubleshooting/general-perf-tips
On Wed, Mar 17, 2021 at 4:21 PM Вячеслав Коптилин
wrote:
> Hi Pavel,
>
> Well, I think that the user should use the right API instead of introducing
> uncontested overhead for everyone.
> For instance, the code that is provided by IEP can changed as follows:
>
> IgniteFuture fut = cache.putAsync(1, 1);
> fut.listenAync(f -> {
> // Executes on Striped pool and deadlocks.
> cache.replace(1, 2);
> }, ForkJoinPool.commonPool());
>
> Of course, it does not mean that this fact should not be properly
> documented.
> Perhaps, I am missing something.
>
> Thanks,
> S.
>
> ср, 17 мар. 2021 г. в 16:01, Pavel Tupitsyn :
>
> > Slava,
> >
> > Your suggestion is to keep things as is and discard the IEP, right?
> >
> > > this can lead to significant overhead
> > Yes, there is some overhead, but the cost of accidentally starving the
> > striped pool is worse,
> > not to mention the deadlocks.
> >
> > I believe that we should favor correctness over performance in any case.
> >
> >
> > On Wed, Mar 17, 2021 at 3:34 PM Вячеслав Коптилин <
> > slava.kopti...@gmail.com>
> > wrote:
> >
> > > Well, the specified method already exists :)
> > >
> > > /**
> > > * Registers listener closure to be asynchronously notified
> whenever
> > > future completes.
> > > * Closure will be processed in specified executor.
> > > *
> > > * @param lsnr Listener closure to register. Cannot be {@code
> null}.
> > > * @param exec Executor to run listener. Cannot be {@code null}.
> > > */
> > > public void listenAsync(IgniteInClosure>
> > lsnr,
> > > Executor exec);
> > >
> > > Thanks,
> > > S.
> > >
> > > ср, 17 мар. 2021 г. в 15:25, Вячеслав Коптилин <
> slava.kopti...@gmail.com
> > >:
> > >
> > > > Hello Pavel,
> > > >
> > > > I took a look at your IEP and pool request. I have the following
> > > concerns.
> > > > First of all, this change breaks the contract of
> > > IgniteFuture#listen(lsnr)
> > > >
> > > > /**
> > > > * Registers listener closure to be asynchronously notified
> > whenever
> > > > future completes.
> > > > * Closure will be processed in thread that completes this future
> > or
> > > > (if future already
> > > > * completed) immediately in current thread.
> > > > *
> > > > * @param lsnr Listener closure to register. Cannot be {@code
> > null}.
> > > > */
> > > > public void listen(IgniteInClosure>
> lsnr);
> > > >
> > > > In your pull request, the listener is always called from a
> > specified
> > > > thread pool (which is fork-join by default)
> > > > even though the future is already completed at the moment the
> > listen
> > > > method is called.
> > > > In my opinion, this can lead to significant overhead - submission
> > > > requires acquiring a lock and notifying a pool thread.
> > > >
> > > > It seems to me, that we should not change the current behavior.
> > > > However, thread pool executor can be added as an optional parameter
> of
> > > > listen() method as follows:
> > > >
> > > > public void listen(IgniteInClosure>
> > lsnr,
> > > > Executor exec);
> > > >
> > > > Thanks,
> > > > S.
> > > >
> > > > пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn :
> > > >
> > > >> Igniters,
> > > >>
> > > >> Please review the IEP [1] and let me know your thoughts.
> > > >>
> > > >> [1]
> > > >>
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor
> > > >>
> > > >
> > >
> >
>
Re: IEP-70: Async Continuation Executor
Hi Pavel,
Well, I think that the user should use the right API instead of introducing
uncontested overhead for everyone.
For instance, the code that is provided by IEP can changed as follows:
IgniteFuture fut = cache.putAsync(1, 1);
fut.listenAync(f -> {
// Executes on Striped pool and deadlocks.
cache.replace(1, 2);
}, ForkJoinPool.commonPool());
Of course, it does not mean that this fact should not be properly
documented.
Perhaps, I am missing something.
Thanks,
S.
ср, 17 мар. 2021 г. в 16:01, Pavel Tupitsyn :
> Slava,
>
> Your suggestion is to keep things as is and discard the IEP, right?
>
> > this can lead to significant overhead
> Yes, there is some overhead, but the cost of accidentally starving the
> striped pool is worse,
> not to mention the deadlocks.
>
> I believe that we should favor correctness over performance in any case.
>
>
> On Wed, Mar 17, 2021 at 3:34 PM Вячеслав Коптилин <
> slava.kopti...@gmail.com>
> wrote:
>
> > Well, the specified method already exists :)
> >
> > /**
> > * Registers listener closure to be asynchronously notified whenever
> > future completes.
> > * Closure will be processed in specified executor.
> > *
> > * @param lsnr Listener closure to register. Cannot be {@code null}.
> > * @param exec Executor to run listener. Cannot be {@code null}.
> > */
> > public void listenAsync(IgniteInClosure>
> lsnr,
> > Executor exec);
> >
> > Thanks,
> > S.
> >
> > ср, 17 мар. 2021 г. в 15:25, Вячеслав Коптилин >:
> >
> > > Hello Pavel,
> > >
> > > I took a look at your IEP and pool request. I have the following
> > concerns.
> > > First of all, this change breaks the contract of
> > IgniteFuture#listen(lsnr)
> > >
> > > /**
> > > * Registers listener closure to be asynchronously notified
> whenever
> > > future completes.
> > > * Closure will be processed in thread that completes this future
> or
> > > (if future already
> > > * completed) immediately in current thread.
> > > *
> > > * @param lsnr Listener closure to register. Cannot be {@code
> null}.
> > > */
> > > public void listen(IgniteInClosure> lsnr);
> > >
> > > In your pull request, the listener is always called from a
> specified
> > > thread pool (which is fork-join by default)
> > > even though the future is already completed at the moment the
> listen
> > > method is called.
> > > In my opinion, this can lead to significant overhead - submission
> > > requires acquiring a lock and notifying a pool thread.
> > >
> > > It seems to me, that we should not change the current behavior.
> > > However, thread pool executor can be added as an optional parameter of
> > > listen() method as follows:
> > >
> > > public void listen(IgniteInClosure>
> lsnr,
> > > Executor exec);
> > >
> > > Thanks,
> > > S.
> > >
> > > пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn :
> > >
> > >> Igniters,
> > >>
> > >> Please review the IEP [1] and let me know your thoughts.
> > >>
> > >> [1]
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor
> > >>
> > >
> >
>
[jira] [Created] (IGNITE-14332) Update for event schedule page
Kseniya Romanova created IGNITE-14332: - Summary: Update for event schedule page Key: IGNITE-14332 URL: https://issues.apache.org/jira/browse/IGNITE-14332 Project: Ignite Issue Type: Task Components: website Reporter: Kseniya Romanova Please update [the events schedule|https://ignite.apache.org/events.html] with the following events: Distributed Java Databases Under the Hood: Main Components and Interactions Seattle Java User Group, Val Kulichenko April 20, 2021 During the session, we create a simple (although fully workable) distributed cache in Java, almost from scratch. We use the cache to demonstrate basic CRUD operations, as well as to demonstrate how scalability can be improved by adding resources to the system. Learn more = https://www.meetup.com/seajug/events/276324545/ Dealing with Network Overhead in Distributed Systems: An Effective Approach to Working with Data DOTNEXT Russia, Pavel Tupitsyn May 20, 21 Modern apps consist of many subsystems: databases, caches, event brokers. The single user request can involve multiple internal network calls. We will talk about data locality, reducing network overhead, improving performance and scalability. Benchmarks, demos, live coding, and practical examples await. Read more = https://dotnext-piter.ru/en/2021/spb/talks/3ar6q8gmbfi86lhbduts0k/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14331) Possible distributed race related to a data streamer flushing leading to a thread being stuck forever trying to close the streamer
Vladimir Pligin created IGNITE-14331:
Summary: Possible distributed race related to a data streamer
flushing leading to a thread being stuck forever trying to close the streamer
Key: IGNITE-14331
URL: https://issues.apache.org/jira/browse/IGNITE-14331
Project: Ignite
Issue Type: Bug
Components: streaming
Affects Versions: 2.10
Reporter: Vladimir Pligin
It seems that a streamer could stuck forever flushing internal buffers on a
client side.
It will stay in a busy-loop forever hoping on remapping but it's possible that
it won't happen for example in case of long GC pauses on server(s) and long
timeouts.
It that case a streamer would be trapped inside this
[loop|https://github.com/apache/ignite/blob/ignite-2.10/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1168].
Stack trace snippet:
{code:java}
java.lang.Thread.State: RUNNABLE at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.flush(DataStreamerImpl.java:1706)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.doFlush(DataStreamerImpl.java:1170)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1365)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1323)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1311)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1415){code}
It becomes possible when a
IgniteSpiOperationTimeoutException
is being thrown from
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: IEP-70: Async Continuation Executor
Slava,
Your suggestion is to keep things as is and discard the IEP, right?
> this can lead to significant overhead
Yes, there is some overhead, but the cost of accidentally starving the
striped pool is worse,
not to mention the deadlocks.
I believe that we should favor correctness over performance in any case.
On Wed, Mar 17, 2021 at 3:34 PM Вячеслав Коптилин
wrote:
> Well, the specified method already exists :)
>
> /**
> * Registers listener closure to be asynchronously notified whenever
> future completes.
> * Closure will be processed in specified executor.
> *
> * @param lsnr Listener closure to register. Cannot be {@code null}.
> * @param exec Executor to run listener. Cannot be {@code null}.
> */
> public void listenAsync(IgniteInClosure> lsnr,
> Executor exec);
>
> Thanks,
> S.
>
> ср, 17 мар. 2021 г. в 15:25, Вячеслав Коптилин :
>
> > Hello Pavel,
> >
> > I took a look at your IEP and pool request. I have the following
> concerns.
> > First of all, this change breaks the contract of
> IgniteFuture#listen(lsnr)
> >
> > /**
> > * Registers listener closure to be asynchronously notified whenever
> > future completes.
> > * Closure will be processed in thread that completes this future or
> > (if future already
> > * completed) immediately in current thread.
> > *
> > * @param lsnr Listener closure to register. Cannot be {@code null}.
> > */
> > public void listen(IgniteInClosure> lsnr);
> >
> > In your pull request, the listener is always called from a specified
> > thread pool (which is fork-join by default)
> > even though the future is already completed at the moment the listen
> > method is called.
> > In my opinion, this can lead to significant overhead - submission
> > requires acquiring a lock and notifying a pool thread.
> >
> > It seems to me, that we should not change the current behavior.
> > However, thread pool executor can be added as an optional parameter of
> > listen() method as follows:
> >
> > public void listen(IgniteInClosure> lsnr,
> > Executor exec);
> >
> > Thanks,
> > S.
> >
> > пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn :
> >
> >> Igniters,
> >>
> >> Please review the IEP [1] and let me know your thoughts.
> >>
> >> [1]
> >>
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor
> >>
> >
>
[jira] [Created] (IGNITE-14330) Implement binary table views API.
Andrey Mashenkov created IGNITE-14330: - Summary: Implement binary table views API. Key: IGNITE-14330 URL: https://issues.apache.org/jira/browse/IGNITE-14330 Project: Ignite Issue Type: Improvement Reporter: Andrey Mashenkov Fix For: 3.0.0-alpha2 Implement KV and Table - binary projections over table. Implement builders for binary objects\rows. Add tests for all operations. Example class is a good start point. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Documentation feedback button
Hi, I agree with Nikita, it would be a very simple way of getting feedback to improve the documentation. This tool in particular is quite easy to integrate into the online docs template. Best, Mauricio On Tue, Mar 16, 2021 at 4:46 PM Denis Magda wrote: > Nikita, thanks for starting the conversation. I'll just cast my vote for > the bugyard.io for its ability to select and comment on a specific > problematic point on a documentation page (a paragraph, sentence, picture, > code snippet, etc.). It makes it trivial to share feedback and then it's > easy to process it on the other side. Those who'd like to experience it, > click the "Documentation Feedback" button on the GridGain docs: > https://www.gridgain.com/docs/latest/getting-started/what-is-gridgain > > - > Denis > > > On Tue, Mar 16, 2021 at 3:14 PM Никита Сафонов > wrote: > > > Hello Igniters, > > > > I would like to propose an enhancement that can significantly improve the > > quality of our documentation. > > > > I suggest adding a feedback button (let’s call it a «Documentation > > feedback» button) to the web site documentation pages so everyone could > > leave a comment to what is already published. > > > > The feedback may refer to the Ignite documentation in general or to a > > particular section, paragraph, or even term or value. > > > > I do believe that we would harvest dozens and hundreds of ideas, > > suggestions, and observations. > > > > I would also suggest using bugyard.io as a solid service for gathering > > feedback (I’m quite familiar with it, it is easy to implement, use, and > > maintain). > > > > So folks, what do you think of this? > > > > With best regards, > > Nikita > > >
Re: IEP-70: Async Continuation Executor
Well, the specified method already exists :)
/**
* Registers listener closure to be asynchronously notified whenever
future completes.
* Closure will be processed in specified executor.
*
* @param lsnr Listener closure to register. Cannot be {@code null}.
* @param exec Executor to run listener. Cannot be {@code null}.
*/
public void listenAsync(IgniteInClosure> lsnr,
Executor exec);
Thanks,
S.
ср, 17 мар. 2021 г. в 15:25, Вячеслав Коптилин :
> Hello Pavel,
>
> I took a look at your IEP and pool request. I have the following concerns.
> First of all, this change breaks the contract of IgniteFuture#listen(lsnr)
>
> /**
> * Registers listener closure to be asynchronously notified whenever
> future completes.
> * Closure will be processed in thread that completes this future or
> (if future already
> * completed) immediately in current thread.
> *
> * @param lsnr Listener closure to register. Cannot be {@code null}.
> */
> public void listen(IgniteInClosure> lsnr);
>
> In your pull request, the listener is always called from a specified
> thread pool (which is fork-join by default)
> even though the future is already completed at the moment the listen
> method is called.
> In my opinion, this can lead to significant overhead - submission
> requires acquiring a lock and notifying a pool thread.
>
> It seems to me, that we should not change the current behavior.
> However, thread pool executor can be added as an optional parameter of
> listen() method as follows:
>
> public void listen(IgniteInClosure> lsnr,
> Executor exec);
>
> Thanks,
> S.
>
> пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn :
>
>> Igniters,
>>
>> Please review the IEP [1] and let me know your thoughts.
>>
>> [1]
>>
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor
>>
>
Re: IEP-70: Async Continuation Executor
Pavel, I got it. Thank you. ср, 17 мар. 2021 г. в 13:11, Pavel Tupitsyn : > Denis, > > Yes, I've updated the Motivation section, it really was a bit vague - thank > you. > > > why you suggest using ForkJoinPool.commonPool as the default pool to run > listeners > > - It is recommended to be used by default [1] > - There are no alternatives? > > [1] > > https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html > > On Wed, Mar 17, 2021 at 1:02 PM Denis Garus wrote: > > > Pavel, thank you for your answer. > > > > Sorry, the previous version of IEP motivation highlighted what could be > > wrong with user listeners, > > so I thought that is the main problem. > > > > I'm wondering why you suggest using ForkJoinPool.commonPool as the > default > > pool to run listeners? > > > > ср, 17 мар. 2021 г. в 11:51, Alexey Kukushkin >: > > > > > My initial confusion was due to I did not know the > > > TaskCompletionSource.SetResult() internally handles > > > SynchronizationContext captured before the async operation. I thought > we > > > would have to do it in Ignite. Now I know that and have no problems > with > > > the IEP. > > > > > > ср, 17 мар. 2021 г. в 11:18, Pavel Tupitsyn : > > > > > > > Denis, > > > > > > > > > we don't try to solve the problem mentioned in the IEP > > > > > > > > The problem: user code executes on striped pool (which causes issues) > > > > The solution: don't execute user code on striped pool > > > > > > > > I believe this solves the problem and removes any and all > restrictions > > > > for async listeners/continuations. Am I missing something else? > > > > > > > > On Wed, Mar 17, 2021 at 10:16 AM Denis Garus > > > wrote: > > > > > > > > > Hello! > > > > > > > > > > As I understood, we don't try to solve the problem mentioned in the > > > IEP: > > > > > there is unexpected behavior, > > > > > users should carefully read the docs to know about this, and so on. > > > > > A thread that executes an incorrect listener hung in any case, > > > > > and the suggested solution is to change the pool which owns this > > > thread. > > > > > Did you consider an option to execute user-defined listeners with a > > > > > timeout? > > > > > I think that implicit using java pools to run a code that can be > hung > > > is > > > > a > > > > > questionable solution. > > > > > > > > > > вт, 16 мар. 2021 г. в 23:30, Alexey Kukushkin < > > > kukushkinale...@gmail.com > > > > >: > > > > > > > > > > > Pavel, > > > > > > > > > > > > So what you are saying is submitting a continuation to .NET > Thread > > > Pool > > > > > > already respects current SynchronizationContext and > > ConfigureAwait. > > > In > > > > > > this case the IEP looks complete (for some reason I thought that > we > > > > > should > > > > > > take care about the SynchronizationContext inside the Ignite.NET > > > > > > implementation). > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > Alexey > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Alexey > > > > > >
Re: IEP-70: Async Continuation Executor
Hello Pavel,
I took a look at your IEP and pool request. I have the following concerns.
First of all, this change breaks the contract of IgniteFuture#listen(lsnr)
/**
* Registers listener closure to be asynchronously notified whenever
future completes.
* Closure will be processed in thread that completes this future or
(if future already
* completed) immediately in current thread.
*
* @param lsnr Listener closure to register. Cannot be {@code null}.
*/
public void listen(IgniteInClosure> lsnr);
In your pull request, the listener is always called from a specified
thread pool (which is fork-join by default)
even though the future is already completed at the moment the listen
method is called.
In my opinion, this can lead to significant overhead - submission
requires acquiring a lock and notifying a pool thread.
It seems to me, that we should not change the current behavior.
However, thread pool executor can be added as an optional parameter of
listen() method as follows:
public void listen(IgniteInClosure> lsnr,
Executor exec);
Thanks,
S.
пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn :
> Igniters,
>
> Please review the IEP [1] and let me know your thoughts.
>
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor
>
Re: IGNITE-2399 : Asynchronous Acquire method in IgniteSemaphore
Hi Valentine, Hoping you are well. Please let me know if the PR looks ok. Regards, Atri On Thu, 11 Mar 2021, 12:09 Atri Sharma, wrote: > Hi Val, > > Thanks for taking a look. I have updated the PR, please see and let me > know your thoughts and feedback. > > Regards, > > Atri > > On Thu, Mar 11, 2021 at 6:16 AM Valentin Kulichenko > wrote: > > > > Atri, > > > > I've added my comments to the PR. > > > > -Val > > > > On Wed, Mar 10, 2021 at 2:44 AM Atri Sharma wrote: > > > > > I have just updated the PR: > > > > > > https://github.com/apache/ignite/pull/8820 > > > > > > Please review. > > > > > > On Wed, Mar 10, 2021 at 1:51 PM Atri Sharma wrote: > > > > > > > > Hi Val, > > > > > > > > Thank you for taking the time on this one. > > > > > > > > The main reason as to why I chose that signature was because I felt > it > > > > gave a clear idea of the interface that the user should expect when > > > > using the method. So essentially, the user is providing a callback > > > > listener himself/herself and the API is just using that to tie the > > > > lifecycle of holding the semaphore. > > > > > > > > However, I do see your point and feel that the current signature that > > > > the PR has will limit the usability of the method and make users jump > > > > through more hoops. I have changed the signature to accept Callable > > > > returning T. > > > > > > > > Regards, > > > > > > > > Atri > > > > > > > > On Wed, Mar 10, 2021 at 5:29 AM Valentin Kulichenko > > > > wrote: > > > > > > > > > > Hi Atri, > > > > > > > > > > First and foremost, we need to clarify the API for this > functionality. > > > > > There are two options presented in the ticket, but no clear > decision > > > about > > > > > which one should be used. I personally think that the original > > > signature > > > > > (the one in the ticket description) makes more sense, but it looks > like > > > > > you've implemented an alternative suggested in the comments. What > was > > > your > > > > > motivation behind that? > > > > > > > > > > As for where the method can be located, I'm OK if we add it > directly > > > to the > > > > > IgniteSemaphore interface. > > > > > > > > > > -Val > > > > > > > > > > On Tue, Mar 9, 2021 at 8:22 AM Atri Sharma > wrote: > > > > > > > > > > > Gentle ping > > > > > > > > > > > > On Mon, 8 Mar 2021, 13:51 Atri Sharma, wrote: > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > I would like to start a discussion around IGNITE-2399. > > > > > > > > > > > > > > Background: The typical use of IgniteSemaphore consists of > > > acquiring > > > > > > > the semaphore, performing the task and releasing the semaphore. > > > This > > > > > > > JIRA proposes a new method which will accept a callable, > acquire > > > the > > > > > > > semaphore, and return a future. Upon completion of the future, > the > > > > > > > semaphore is released. > > > > > > > > > > > > > > This API seems useful for an easy encapsulation of the > described > > > use > > > > > > > case and does not cause an internal flux since all the changes > are > > > > > > > focused at the public API. > > > > > > > > > > > > > > WIP PR for the same: > > > > > > > > > > > > > > https://github.com/apache/ignite/pull/8820 > > > > > > > > > > > > > > Please share your thoughts and comments. > > > > > > > > > > > > > > -- > > > > > > > Regards, > > > > > > > > > > > > > > Atri > > > > > > > Apache Concerted > > > > > > > > > > > > > > > > > > > > > -- > > > > Regards, > > > > > > > > Atri > > > > Apache Concerted > > > > > > > > > > > > -- > > > Regards, > > > > > > Atri > > > Apache Concerted > > > > > -- > Regards, > > Atri > Apache Concerted >
[jira] [Created] (IGNITE-14329) Set 2.9.1 as LATEST_2.9 and 2.10 as LATEST
Anton Vinogradov created IGNITE-14329: - Summary: Set 2.9.1 as LATEST_2.9 and 2.10 as LATEST Key: IGNITE-14329 URL: https://issues.apache.org/jira/browse/IGNITE-14329 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov This fixed nightly run failures fixed at IGNITE-13705. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Maxim, I've prepared a blog post about Ignite.NET changes [1], please link it in the main post. [1] https://ptupitsyn.github.io/Whats-New-In-Ignite-Net-2.10/ On Tue, Mar 16, 2021 at 5:15 PM Maxim Muzafarov wrote: > Denis, > > > Thank you. I'll prepare a blog post notes for the major 2.10 features. > The release hasn't been announced yet, some artefacts still waiting to > be published. Hope everything will be ready by the end of this week. > > > > Btw, don't we want to arrange a meetup gathering for Virtual or > Russian-speaking meetup or both? > > It depends on our goals. If we want to promote Ignite Summit 2021, so > the English-speaking meetup makes sense. > > On Tue, 16 Mar 2021 at 16:00, Denis Magda wrote: > > > > Hi Maxim, > > > > Ideally, a blog post should be published together with the announcement > > email. So that the readers can learn more details from the article. > Anyway, > > you can post it later for 2.10 as long as the release is already > completed. > > > > Btw, don't we want to arrange a meetup gathering for Virtual or > > Russian-speaking meetup, or both? > > > > - > > Denis > > > > > > On Mon, Mar 15, 2021 at 8:55 PM Maxim Muzafarov > wrote: > > > > > Folks, > > > > > > I've done almost all the release steps with publishing accepted > changes. > > > What should I do with an announcement blog post for blogs.apache.org? > > > Should it also be prepared prior to an announcement message? > > > > > > On Thu, 11 Mar 2021 at 00:10, Maxim Muzafarov > wrote: > > > > > > > > Pavel, > > > > > > > > Thank you! I'll prepare a new rc shortly. > > > > > > > > On Wed, 10 Mar 2021 at 23:20, Pavel Tupitsyn > > > wrote: > > > > > > > > > > Maxim, thanks! > > > > > I've cherry-picked IGNITE-14293. > > > > > > > > > > On Wed, Mar 10, 2021 at 10:05 PM Maxim Muzafarov < > mmu...@apache.org> > > > wrote: > > > > > > > > > > > Pavel, > > > > > > > > > > > > Sorry, my bad. Entangled in my local branches during trying to > > > > > > cherry-pick related commits. > > > > > > I've reverted this change. > > > > > > > > > > > > > > > > > > On Wed, 10 Mar 2021 at 21:58, Pavel Tupitsyn < > ptupit...@apache.org> > > > wrote: > > > > > > > > > > > > > > Maxim, > > > > > > > > > > > > > > I see that you have already cherry-picked IGNITE-13979 - was > that > > > > > > > intentional? > > > > > > > If we keep it, let's cherry-pick 14250 as well? > > > > > > > > > > > > > > On Wed, Mar 10, 2021 at 8:21 PM Maxim Muzafarov < > mmu...@apache.org > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Pavel, > > > > > > > > > > > > > > > > > > > > > > > > I think it is better and safe to cherry-pick the > `IGNITE-14293 > > > .NET: > > > > > > > > AffinityKey does not work` only. I will be very happy to > accept > > > your > > > > > > > > help with it. > > > > > > > > > > > > > > > > > > > > > > > > The IGNITE-13979 (.NET: Modernize examples) is very big and > has > > > some > > > > > > > > related issues too (most of them are fixed), so I think it is > > > better > > > > > > > > here to postpone it to the next release and give it a bit of > > > time for > > > > > > > > the self-stabilization process :-) > > > > > > > > > > > > > > > > On Wed, 10 Mar 2021 at 20:17, Pavel Tupitsyn < > > > ptupit...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > > > > > > Maxim, > > > > > > > > > > > > > > > > > > Sure, I can assist with cherry-picks. > > > > > > > > > > > > > > > > > > 13661 is fixed by 13979, as indicated by the "fixed by" > link > > > in Jira > > > > > > and > > > > > > > > a comment. > > > > > > > > > > > > > > > > > > IGNITE-14293 .NET: AffinityKey does not work is quite an > > > unpleasant > > > > > > > > regression, > > > > > > > > > I think we should include it in the release. It CAN be > included > > > > > > without > > > > > > > > 14250 and 13979. > > > > > > > > > > > > > > > > > > 14250 does not make sense without 13979. > > > > > > > > > > > > > > > > > > Ultimately, the question is - do we want to include 13979 > > > (.NET: > > > > > > > > Modernize examples), > > > > > > > > > or not. Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 10, 2021 at 7:45 PM Maxim Muzafarov < > > > mmu...@apache.org> > > > > > > > > wrote: > > > > > > > > >> > > > > > > > > >> Pavel, > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> Can you assist a bit with the cherry-picking process of > `.NET: > > > > > > > > >> AffinityKey does not work` IGNITE-14293? I'm not sure I > can > > > > > > understand > > > > > > > > >> all the details of implementation and actually, I'm stuck > a > > > bit with > > > > > > > > >> the `.NET: Race condition in Events example` IGNITE-14250 > [2] > > > issue > > > > > > > > >> not sure what exactly I can exclude from the commit to > resolve > > > > > > > > >> conflicts since it has some of them with the 2.10 branch. > I'm > > > > > > worried > > > > > > > > >> about missing some important parts of the code. > > > > > > > > >> > > > > > > > > >> > > > > > > > >
Re: IEP-70: Async Continuation Executor
Denis, Yes, I've updated the Motivation section, it really was a bit vague - thank you. > why you suggest using ForkJoinPool.commonPool as the default pool to run listeners - It is recommended to be used by default [1] - There are no alternatives? [1] https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html On Wed, Mar 17, 2021 at 1:02 PM Denis Garus wrote: > Pavel, thank you for your answer. > > Sorry, the previous version of IEP motivation highlighted what could be > wrong with user listeners, > so I thought that is the main problem. > > I'm wondering why you suggest using ForkJoinPool.commonPool as the default > pool to run listeners? > > ср, 17 мар. 2021 г. в 11:51, Alexey Kukushkin : > > > My initial confusion was due to I did not know the > > TaskCompletionSource.SetResult() internally handles > > SynchronizationContext captured before the async operation. I thought we > > would have to do it in Ignite. Now I know that and have no problems with > > the IEP. > > > > ср, 17 мар. 2021 г. в 11:18, Pavel Tupitsyn : > > > > > Denis, > > > > > > > we don't try to solve the problem mentioned in the IEP > > > > > > The problem: user code executes on striped pool (which causes issues) > > > The solution: don't execute user code on striped pool > > > > > > I believe this solves the problem and removes any and all restrictions > > > for async listeners/continuations. Am I missing something else? > > > > > > On Wed, Mar 17, 2021 at 10:16 AM Denis Garus > > wrote: > > > > > > > Hello! > > > > > > > > As I understood, we don't try to solve the problem mentioned in the > > IEP: > > > > there is unexpected behavior, > > > > users should carefully read the docs to know about this, and so on. > > > > A thread that executes an incorrect listener hung in any case, > > > > and the suggested solution is to change the pool which owns this > > thread. > > > > Did you consider an option to execute user-defined listeners with a > > > > timeout? > > > > I think that implicit using java pools to run a code that can be hung > > is > > > a > > > > questionable solution. > > > > > > > > вт, 16 мар. 2021 г. в 23:30, Alexey Kukushkin < > > kukushkinale...@gmail.com > > > >: > > > > > > > > > Pavel, > > > > > > > > > > So what you are saying is submitting a continuation to .NET Thread > > Pool > > > > > already respects current SynchronizationContext and > ConfigureAwait. > > In > > > > > this case the IEP looks complete (for some reason I thought that we > > > > should > > > > > take care about the SynchronizationContext inside the Ignite.NET > > > > > implementation). > > > > > > > > > > -- > > > > > Best regards, > > > > > Alexey > > > > > > > > > > > > > > > > > > -- > > Best regards, > > Alexey > > >
Re: IEP-70: Async Continuation Executor
Pavel, thank you for your answer. Sorry, the previous version of IEP motivation highlighted what could be wrong with user listeners, so I thought that is the main problem. I'm wondering why you suggest using ForkJoinPool.commonPool as the default pool to run listeners? ср, 17 мар. 2021 г. в 11:51, Alexey Kukushkin : > My initial confusion was due to I did not know the > TaskCompletionSource.SetResult() internally handles > SynchronizationContext captured before the async operation. I thought we > would have to do it in Ignite. Now I know that and have no problems with > the IEP. > > ср, 17 мар. 2021 г. в 11:18, Pavel Tupitsyn : > > > Denis, > > > > > we don't try to solve the problem mentioned in the IEP > > > > The problem: user code executes on striped pool (which causes issues) > > The solution: don't execute user code on striped pool > > > > I believe this solves the problem and removes any and all restrictions > > for async listeners/continuations. Am I missing something else? > > > > On Wed, Mar 17, 2021 at 10:16 AM Denis Garus > wrote: > > > > > Hello! > > > > > > As I understood, we don't try to solve the problem mentioned in the > IEP: > > > there is unexpected behavior, > > > users should carefully read the docs to know about this, and so on. > > > A thread that executes an incorrect listener hung in any case, > > > and the suggested solution is to change the pool which owns this > thread. > > > Did you consider an option to execute user-defined listeners with a > > > timeout? > > > I think that implicit using java pools to run a code that can be hung > is > > a > > > questionable solution. > > > > > > вт, 16 мар. 2021 г. в 23:30, Alexey Kukushkin < > kukushkinale...@gmail.com > > >: > > > > > > > Pavel, > > > > > > > > So what you are saying is submitting a continuation to .NET Thread > Pool > > > > already respects current SynchronizationContext and ConfigureAwait. > In > > > > this case the IEP looks complete (for some reason I thought that we > > > should > > > > take care about the SynchronizationContext inside the Ignite.NET > > > > implementation). > > > > > > > > -- > > > > Best regards, > > > > Alexey > > > > > > > > > > > > -- > Best regards, > Alexey >
Re: Adding metrics of using WAL archive
Hi Nikolay! Can you do an additional review or can we merge? 15.03.2021, 08:48, "ткаленко кирилл" : > Hi Nikolay! Can you do an additional review or can we merge? > > 05.03.2021, 16:33, "Nikolay Izhikov" : >> Yes, definitely. >> >>> 5 марта 2021 г., в 16:31, ткаленко кирилл >>> написал(а): >>> >>> Hi Nikolay, can you do a review? >>> >>> 02.03.2021, 18:59, "Nikolay Izhikov" : +1 For this. > 2 марта 2021 г., в 18:32, ткаленко кирилл > написал(а): > > Hi, Nikolay! > > I thought about your proposal and offer the following two metrics: > > 1)The number of bytes logged to the WAL; > 2)The number of compressed bytes in the WAL. > > Monotonically increasing long. > > WDYT?
[jira] [Created] (IGNITE-14328) .NET: Array of Collections can't be used as service method parameters
Nikolay Izhikov created IGNITE-14328:
Summary: .NET: Array of Collections can't be used as service
method parameters
Key: IGNITE-14328
URL: https://issues.apache.org/jira/browse/IGNITE-14328
Project: Ignite
Issue Type: Improvement
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
Currently, collections (list, map) can't be used as a service method parameter
in case of
.Net (client node) -> .Net (server node) call.
This can be reproduced my one line modification of
{{ServicesTypeAutoResolveTest#DoTestPlatformService}}
{code:java}
///
/// Tests .Net service invocation.
///
public void DoTestPlatformService(IServices svcsForProxy)
{
const string platformSvcName = "PlatformTestService";
_grid1.GetServices().DeployClusterSingleton(platformSvcName, new
PlatformTestService());
var svc =
svcsForProxy.GetServiceProxy(platformSvcName);
DoTestService(svc);
DoTestCollections(svc); // This line was added.
_grid1.GetServices().Cancel(platformSvcName);
}
{code}
Exception:
{noformat}
Apache.Ignite.Core.Services.ServiceInvocationException : Proxy method
invocation failed with an exception. Examine InnerException for details.
> Apache.Ignite.Core.Common.IgniteException : No matching type found for
object [typeId=1552553483,
typeName=org.system.collections.generic.List`1[[org.apache.ignite.platform.model.department,
apache.ignite.core.testDepartment]]]. This usually indicates that assembly
with specified type is not loaded on a node. When using Apache.Ignite.exe, make
sure to load assemblies with -assembly parameter. Alternatively, set
IgniteConfiguration.PeerAssemblyLoadingMode to CurrentAppDomain.
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSSION] IEP-69 The evolutionary release process
Maksim, Great summary! +1 for versioning scheme. However, deprecation rules can be possibly misleading. I think that we should use 'since' as a mandatory annotation, that will mark the release where the API can (not should) be changed, regardless of our intention to modify it. And add some kind of a tag or alike to that APIs only that we need to update/remove since mentioned release. Otherwise, I think, simple deprecation annotation will raise questions 'when it was deprecated' or 'is it already time to update/remove deprecated API'. Also, if agreed on 'since' annotation usage, we possibly should create the issue to tag all current deprecated APIs with since where applicable. > On 16 Mar 2021, at 21:05, Maxim Muzafarov wrote: > > Folks, > > > Thanks to everyone for participating in the call. Here is the list of > points we've agreed on and the list of actions which should be > discussed in more details. > > > = AGREED = > > == Versioning == > > grand.major.bugfix[-rc_number] > > The 'grand' version is fixed while both Ignite architectures (current > version 2.x and 3.x) are in a state of active development/maintained > or until otherwise is discussed further. This means: > - the master branch of the ignite repository [2] always release under > the '2.x.x' version > - the main branch of the ignite-3 repository [1] always release under > the '3.x.x' version > > The 'major' versions for each architecture may contain breaking > backwards compatibility changes compared to the previous one if the > following criteria are met: > - users should be warned about breaking release changes (the ways of > notification should be additionally discussed and agreed upon) > - the deprecation rules may be applied for the current 'major' release > (the ways of deprecation must be additionally discussed and agreed > upon) > - current @deprecated already have enough time live and some of them > can be removed using common sense > > The 'bugfix' version is used for emergency releases and can't contain > any breaking backwards compatibility changes. > > == Commitments == > > Any commitment to support previous releases (e.g. 1 year, 1 quarter) > have no sense to the open-source Ignite community in the case of > observed backward compatibility violations, however, in any of such > cases, an emergency release can be performed according to the accepted > release procedure. > > > = DISCUSSION & SUGGESTIONS = > > > == Deprecation rules == > > The API deprecation rules must be discussed and agreed upon in more > details. The list of options we have: > - deprecate and remove API allowed in the next release > - deprecate and remove API allowed through the one release > - deprecation may contain comments - the release version then the API > will be changed > - deprecation may contain comments - the date from which the API changes > allowed > > I've checked the `JEP 277 Enhanced Deprecation` [3] proposal which > adds the `forRemoval` and `since` optional elements to the deprecated > annotation and I think we can use a similar approach here with some > additions. For instance, if the last released version is 2.10 my > suggestions would be the following: > - [case: change API as quickly as possible] mark some API as > deprecated, set 'since' version 2.12, change it in the 2.12 release > major version. > - [case: deprecate API without intention to change] mark API as > deprecated without 'since' options, change it without notifications > since 2.13 releases and so on. > > > == User notification rules == > > Uses must be well-notified about the planned backward compatibility > violations. The options we have: > - the notification thought the source code with well-described JavaDocs > - add labels to the JIRA issue if some deprecations occur in the related patch > - add deprecation and backward compatibility paragraph to the RELEASE_NOTES > - add a page to the Apache Ignite website with a backwards > compatibility description between the closest versions > > All of the above must be done. > > > == Experimental and unstable APIs == > > The options we have: > - only the new API can be marked as unstable and/or experimental > - such APIs can be changed without any notifications > > > Please, share your thoughts. > > > [1] https://github.com/apache/ignite-3 > [2] https://github.com/apache/ignite > [3] https://openjdk.java.net/jeps/277 > > On Mon, 15 Mar 2021 at 19:41, Dmitriy Pavlov wrote: >> >> Folks, >> >> let me add my 50 cents. I don't see major issues with this IEP, for now. >> And I really looking forward to talking about it. I can't get what causes >> misunderstanding. >> >> The only thing that concerns me here is that IEP requires the community to >> support solutions for 1 year, 1 quarter, etc. >> >> Apache community is not a commercial company that provides support of any >> kind, and I would be reluctant to add these or similar statements to any >> public documents. At any point in time, the
Re: IEP-70: Async Continuation Executor
My initial confusion was due to I did not know the TaskCompletionSource.SetResult() internally handles SynchronizationContext captured before the async operation. I thought we would have to do it in Ignite. Now I know that and have no problems with the IEP. ср, 17 мар. 2021 г. в 11:18, Pavel Tupitsyn : > Denis, > > > we don't try to solve the problem mentioned in the IEP > > The problem: user code executes on striped pool (which causes issues) > The solution: don't execute user code on striped pool > > I believe this solves the problem and removes any and all restrictions > for async listeners/continuations. Am I missing something else? > > On Wed, Mar 17, 2021 at 10:16 AM Denis Garus wrote: > > > Hello! > > > > As I understood, we don't try to solve the problem mentioned in the IEP: > > there is unexpected behavior, > > users should carefully read the docs to know about this, and so on. > > A thread that executes an incorrect listener hung in any case, > > and the suggested solution is to change the pool which owns this thread. > > Did you consider an option to execute user-defined listeners with a > > timeout? > > I think that implicit using java pools to run a code that can be hung is > a > > questionable solution. > > > > вт, 16 мар. 2021 г. в 23:30, Alexey Kukushkin >: > > > > > Pavel, > > > > > > So what you are saying is submitting a continuation to .NET Thread Pool > > > already respects current SynchronizationContext and ConfigureAwait. In > > > this case the IEP looks complete (for some reason I thought that we > > should > > > take care about the SynchronizationContext inside the Ignite.NET > > > implementation). > > > > > > -- > > > Best regards, > > > Alexey > > > > > > -- Best regards, Alexey
Re: IEP-54: Schema-first approach for 3.0
I see, thanks.
Let's discuss the return type - Future is not the one to use.
We should return CompletionStage, CompletableFuture, or introduce our own
interface.
We agreed on the last one (custom interface) for thin clients:
http://apache-ignite-developers.2346864.n4.nabble.com/IEP-51-Java-Thin-Client-Async-API-td48900.html
I believe that for Ignite 3.0 we should have the following:
public interface IgniteFuture extends Future, CompletionStage {
// No-op.
}
Thoughts?
On Wed, Mar 17, 2021 at 11:16 AM Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:
> Pavel,
> There are 2 PR's for the ticket[1] with two different APIs suggested.
> Please, take a look at PR [2].
>
> [1] https://issues.apache.org/jira/browse/IGNITE-14035
> [2] https://github.com/apache/ignite-3/pull/69
>
> On Wed, Mar 17, 2021 at 11:11 AM Pavel Tupitsyn
> wrote:
>
> > Andrey, I can't find any async methods,
> > can you please check if the changes are pushed?
> >
> > On Tue, Mar 16, 2021 at 10:06 PM Andrey Mashenkov <
> > andrey.mashen...@gmail.com> wrote:
> >
> > > Pavel, good point.
> > > Thanks. I've added async methods.
> > >
> > > On Fri, Mar 12, 2021 at 2:29 PM Pavel Tupitsyn
> > > wrote:
> > >
> > > > Andrey,
> > > >
> > > > What about corresponding async APIs, do we add them now or later?
> > > >
> > > > On Thu, Mar 11, 2021 at 8:11 PM Andrey Mashenkov <
> > > > andrey.mashen...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Igniters.
> > > > >
> > > > > I've created a PR for Table access API [1].
> > > > > This is an initial version. So, any suggestions\objections are
> > > welcomed.
> > > > > Please, do not hesitate to write your comments and\or examples to
> the
> > > PR.
> > > > >
> > > > > Ignite-api module contains API classes, e.g. TableView classes as
> > > > > projections for a table for different purposes.
> > > > > Ignite-table contains dummy implementation and Example class
> > explained
> > > > how
> > > > > it is supposed to be used.
> > > > >
> > > > >
> > > > > Also, I'm still waiting for any feedback for Schema configuration
> > > public
> > > > > API PR [2].
> > > > >
> > > > > [1] https://github.com/apache/ignite-3/pull/33
> > > > > [2] https://github.com/apache/ignite-3/pull/2
> > > > >
> > > > > On Wed, Jan 20, 2021 at 6:05 PM Andrey Mashenkov <
> > > > > andrey.mashen...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > I've updated a PR regarding your feedback [1].
> > > > > >
> > > > > > [1] https://github.com/apache/ignite-3/pull/2
> > > > > >
> > > > > > On Mon, Jan 11, 2021 at 10:58 AM Alexey Goncharuk <
> > > > > > alexey.goncha...@gmail.com> wrote:
> > > > > >
> > > > > >> Folks,
> > > > > >>
> > > > > >> I updated the IEP to contain the missing pieces; actually, most
> of
> > > the
> > > > > >> questions here were covered by the text. Please let me know if
> > there
> > > > is
> > > > > >> something still missing or unclear.
> > > > > >>
> > > > > >> чт, 31 дек. 2020 г. в 12:48, Alexey Goncharuk <
> > > > > alexey.goncha...@gmail.com
> > > > > >> >:
> > > > > >>
> > > > > >> > Mikhail and Igniters,
> > > > > >> >
> > > > > >> > Thanks for your comments. The questions are reasonable,
> though I
> > > > think
> > > > > >> all
> > > > > >> > concerns are addressed by the IEP as Val mentioned. I will
> > update
> > > > the
> > > > > >> > document according to your questions in the following week or
> > so,
> > > so
> > > > > we
> > > > > >> can
> > > > > >> > have a constructive discussion further.
> > > > > >> >
> > > > > >> > ср, 30 дек. 2020 г. в 11:45, Michael Cherkasov <
> > > > > >> > michael.cherka...@gmail.com>:
> > > > > >> >
> > > > > >> >> Hi Val, Andrey,
> > > > > >> >>
> > > > > >> >> thank you for clarifying.
> > > > > >> >>
> > > > > >> >> I still have a few comments.
> > > > > >> >>
> > > > > >> >> 1. one table == one schema. KV vs SQL:
> > > > > >> >> Looks like all agreed that KV is just a special case of a
> > regular
> > > > > table
> > > > > >> >> with (blob,blob) schema.
> > > > > >> >> I worry about the case when the user starts from KV case and
> > > later
> > > > > will
> > > > > >> >> try
> > > > > >> >> to expand it and try to leverage SQL for the existing KV
> table
> > it
> > > > > >> won't be
> > > > > >> >> able to do so and will require to reload data. which isn't
> > > > convenient
> > > > > >> and
> > > > > >> >> sometimes not even possible. Is it possible to extract a new
> > > field
> > > > > from
> > > > > >> >> (blob, blob) schema and apply index on it?
> > > > > >> >>
> > > > > >> >> 2. Could you please also list all ways of schema definition
> in
> > > the
> > > > > >> IEP? It
> > > > > >> >> significant change and I bet the main point of this IEP,
> > everyone
> > > > > hates
> > > > > >> >> QueryEntities, they are difficult to manage and in general,
> > it's
> > > > very
> > > > > >> >> confusing to have a data model(schemas) and node/cluster
> > > > > configuration
> > > > > >> in
> > > > > >> >> one place.
> > > > > >> >>
> > > > > >> >>
Re: IEP-70: Async Continuation Executor
Denis, > we don't try to solve the problem mentioned in the IEP The problem: user code executes on striped pool (which causes issues) The solution: don't execute user code on striped pool I believe this solves the problem and removes any and all restrictions for async listeners/continuations. Am I missing something else? On Wed, Mar 17, 2021 at 10:16 AM Denis Garus wrote: > Hello! > > As I understood, we don't try to solve the problem mentioned in the IEP: > there is unexpected behavior, > users should carefully read the docs to know about this, and so on. > A thread that executes an incorrect listener hung in any case, > and the suggested solution is to change the pool which owns this thread. > Did you consider an option to execute user-defined listeners with a > timeout? > I think that implicit using java pools to run a code that can be hung is a > questionable solution. > > вт, 16 мар. 2021 г. в 23:30, Alexey Kukushkin : > > > Pavel, > > > > So what you are saying is submitting a continuation to .NET Thread Pool > > already respects current SynchronizationContext and ConfigureAwait. In > > this case the IEP looks complete (for some reason I thought that we > should > > take care about the SynchronizationContext inside the Ignite.NET > > implementation). > > > > -- > > Best regards, > > Alexey > > >
Re: IEP-54: Schema-first approach for 3.0
Pavel, There are 2 PR's for the ticket[1] with two different APIs suggested. Please, take a look at PR [2]. [1] https://issues.apache.org/jira/browse/IGNITE-14035 [2] https://github.com/apache/ignite-3/pull/69 On Wed, Mar 17, 2021 at 11:11 AM Pavel Tupitsyn wrote: > Andrey, I can't find any async methods, > can you please check if the changes are pushed? > > On Tue, Mar 16, 2021 at 10:06 PM Andrey Mashenkov < > andrey.mashen...@gmail.com> wrote: > > > Pavel, good point. > > Thanks. I've added async methods. > > > > On Fri, Mar 12, 2021 at 2:29 PM Pavel Tupitsyn > > wrote: > > > > > Andrey, > > > > > > What about corresponding async APIs, do we add them now or later? > > > > > > On Thu, Mar 11, 2021 at 8:11 PM Andrey Mashenkov < > > > andrey.mashen...@gmail.com> > > > wrote: > > > > > > > Hi Igniters. > > > > > > > > I've created a PR for Table access API [1]. > > > > This is an initial version. So, any suggestions\objections are > > welcomed. > > > > Please, do not hesitate to write your comments and\or examples to the > > PR. > > > > > > > > Ignite-api module contains API classes, e.g. TableView classes as > > > > projections for a table for different purposes. > > > > Ignite-table contains dummy implementation and Example class > explained > > > how > > > > it is supposed to be used. > > > > > > > > > > > > Also, I'm still waiting for any feedback for Schema configuration > > public > > > > API PR [2]. > > > > > > > > [1] https://github.com/apache/ignite-3/pull/33 > > > > [2] https://github.com/apache/ignite-3/pull/2 > > > > > > > > On Wed, Jan 20, 2021 at 6:05 PM Andrey Mashenkov < > > > > andrey.mashen...@gmail.com> > > > > wrote: > > > > > > > > > > > > > > I've updated a PR regarding your feedback [1]. > > > > > > > > > > [1] https://github.com/apache/ignite-3/pull/2 > > > > > > > > > > On Mon, Jan 11, 2021 at 10:58 AM Alexey Goncharuk < > > > > > alexey.goncha...@gmail.com> wrote: > > > > > > > > > >> Folks, > > > > >> > > > > >> I updated the IEP to contain the missing pieces; actually, most of > > the > > > > >> questions here were covered by the text. Please let me know if > there > > > is > > > > >> something still missing or unclear. > > > > >> > > > > >> чт, 31 дек. 2020 г. в 12:48, Alexey Goncharuk < > > > > alexey.goncha...@gmail.com > > > > >> >: > > > > >> > > > > >> > Mikhail and Igniters, > > > > >> > > > > > >> > Thanks for your comments. The questions are reasonable, though I > > > think > > > > >> all > > > > >> > concerns are addressed by the IEP as Val mentioned. I will > update > > > the > > > > >> > document according to your questions in the following week or > so, > > so > > > > we > > > > >> can > > > > >> > have a constructive discussion further. > > > > >> > > > > > >> > ср, 30 дек. 2020 г. в 11:45, Michael Cherkasov < > > > > >> > michael.cherka...@gmail.com>: > > > > >> > > > > > >> >> Hi Val, Andrey, > > > > >> >> > > > > >> >> thank you for clarifying. > > > > >> >> > > > > >> >> I still have a few comments. > > > > >> >> > > > > >> >> 1. one table == one schema. KV vs SQL: > > > > >> >> Looks like all agreed that KV is just a special case of a > regular > > > > table > > > > >> >> with (blob,blob) schema. > > > > >> >> I worry about the case when the user starts from KV case and > > later > > > > will > > > > >> >> try > > > > >> >> to expand it and try to leverage SQL for the existing KV table > it > > > > >> won't be > > > > >> >> able to do so and will require to reload data. which isn't > > > convenient > > > > >> and > > > > >> >> sometimes not even possible. Is it possible to extract a new > > field > > > > from > > > > >> >> (blob, blob) schema and apply index on it? > > > > >> >> > > > > >> >> 2. Could you please also list all ways of schema definition in > > the > > > > >> IEP? It > > > > >> >> significant change and I bet the main point of this IEP, > everyone > > > > hates > > > > >> >> QueryEntities, they are difficult to manage and in general, > it's > > > very > > > > >> >> confusing to have a data model(schemas) and node/cluster > > > > configuration > > > > >> in > > > > >> >> one place. > > > > >> >> > > > > >> >> So there will be SchemaBuilder and SQL to define schemas, but > > > Andrey > > > > >> also > > > > >> >> mentioned annotations. > > > > >> >> > > > > >> >> I personally against configuration via annotations, while it's > > > > >> convenient > > > > >> >> for development, it difficult to manage because different > classes > > > can > > > > >> be > > > > >> >> deployed on different clients/servers nodes and it can lead to > > > > >> >> unpredictable results. > > > > >> >> > > > > >> >> 3. IEP doesn't mention field type changes, only drop/add > fields. > > > > Field > > > > >> >> type > > > > >> >> changes are extremely painful right now(if even possible), so > it > > > > would > > > > >> be > > > > >> >> nice if some scenarios would be supported(like int8->int16, or > > > > >> >> int8->String). > > > > >> >> > > > > >> >> 4. got it, I thoug
Re: IEP-54: Schema-first approach for 3.0
Andrey, I can't find any async methods, can you please check if the changes are pushed? On Tue, Mar 16, 2021 at 10:06 PM Andrey Mashenkov < andrey.mashen...@gmail.com> wrote: > Pavel, good point. > Thanks. I've added async methods. > > On Fri, Mar 12, 2021 at 2:29 PM Pavel Tupitsyn > wrote: > > > Andrey, > > > > What about corresponding async APIs, do we add them now or later? > > > > On Thu, Mar 11, 2021 at 8:11 PM Andrey Mashenkov < > > andrey.mashen...@gmail.com> > > wrote: > > > > > Hi Igniters. > > > > > > I've created a PR for Table access API [1]. > > > This is an initial version. So, any suggestions\objections are > welcomed. > > > Please, do not hesitate to write your comments and\or examples to the > PR. > > > > > > Ignite-api module contains API classes, e.g. TableView classes as > > > projections for a table for different purposes. > > > Ignite-table contains dummy implementation and Example class explained > > how > > > it is supposed to be used. > > > > > > > > > Also, I'm still waiting for any feedback for Schema configuration > public > > > API PR [2]. > > > > > > [1] https://github.com/apache/ignite-3/pull/33 > > > [2] https://github.com/apache/ignite-3/pull/2 > > > > > > On Wed, Jan 20, 2021 at 6:05 PM Andrey Mashenkov < > > > andrey.mashen...@gmail.com> > > > wrote: > > > > > > > > > > > I've updated a PR regarding your feedback [1]. > > > > > > > > [1] https://github.com/apache/ignite-3/pull/2 > > > > > > > > On Mon, Jan 11, 2021 at 10:58 AM Alexey Goncharuk < > > > > alexey.goncha...@gmail.com> wrote: > > > > > > > >> Folks, > > > >> > > > >> I updated the IEP to contain the missing pieces; actually, most of > the > > > >> questions here were covered by the text. Please let me know if there > > is > > > >> something still missing or unclear. > > > >> > > > >> чт, 31 дек. 2020 г. в 12:48, Alexey Goncharuk < > > > alexey.goncha...@gmail.com > > > >> >: > > > >> > > > >> > Mikhail and Igniters, > > > >> > > > > >> > Thanks for your comments. The questions are reasonable, though I > > think > > > >> all > > > >> > concerns are addressed by the IEP as Val mentioned. I will update > > the > > > >> > document according to your questions in the following week or so, > so > > > we > > > >> can > > > >> > have a constructive discussion further. > > > >> > > > > >> > ср, 30 дек. 2020 г. в 11:45, Michael Cherkasov < > > > >> > michael.cherka...@gmail.com>: > > > >> > > > > >> >> Hi Val, Andrey, > > > >> >> > > > >> >> thank you for clarifying. > > > >> >> > > > >> >> I still have a few comments. > > > >> >> > > > >> >> 1. one table == one schema. KV vs SQL: > > > >> >> Looks like all agreed that KV is just a special case of a regular > > > table > > > >> >> with (blob,blob) schema. > > > >> >> I worry about the case when the user starts from KV case and > later > > > will > > > >> >> try > > > >> >> to expand it and try to leverage SQL for the existing KV table it > > > >> won't be > > > >> >> able to do so and will require to reload data. which isn't > > convenient > > > >> and > > > >> >> sometimes not even possible. Is it possible to extract a new > field > > > from > > > >> >> (blob, blob) schema and apply index on it? > > > >> >> > > > >> >> 2. Could you please also list all ways of schema definition in > the > > > >> IEP? It > > > >> >> significant change and I bet the main point of this IEP, everyone > > > hates > > > >> >> QueryEntities, they are difficult to manage and in general, it's > > very > > > >> >> confusing to have a data model(schemas) and node/cluster > > > configuration > > > >> in > > > >> >> one place. > > > >> >> > > > >> >> So there will be SchemaBuilder and SQL to define schemas, but > > Andrey > > > >> also > > > >> >> mentioned annotations. > > > >> >> > > > >> >> I personally against configuration via annotations, while it's > > > >> convenient > > > >> >> for development, it difficult to manage because different classes > > can > > > >> be > > > >> >> deployed on different clients/servers nodes and it can lead to > > > >> >> unpredictable results. > > > >> >> > > > >> >> 3. IEP doesn't mention field type changes, only drop/add fields. > > > Field > > > >> >> type > > > >> >> changes are extremely painful right now(if even possible), so it > > > would > > > >> be > > > >> >> nice if some scenarios would be supported(like int8->int16, or > > > >> >> int8->String). > > > >> >> > > > >> >> 4. got it, I thought IEP will have more details about the > > > >> implementation. > > > >> >> I've seen Andrey even sent benchmark results for a new > > serialization, > > > >> will > > > >> >> ping him about this. > > > >> >> > > > >> >> 5. Thanks for the clarification. I had a wrong understanding of > > > strick > > > >> >> mode. > > > >> >> > > > >> >> > > > >> >> вт, 29 дек. 2020 г. в 19:32, Valentin Kulichenko < > > > >> >> valentin.kuliche...@gmail.com>: > > > >> >> > > > >> >> > Hi Mike, > > > >> >> > > > > >> >> > Thanks for providing your feedback. Please see my comments >
Re: IEP-70: Async Continuation Executor
Hello! As I understood, we don't try to solve the problem mentioned in the IEP: there is unexpected behavior, users should carefully read the docs to know about this, and so on. A thread that executes an incorrect listener hung in any case, and the suggested solution is to change the pool which owns this thread. Did you consider an option to execute user-defined listeners with a timeout? I think that implicit using java pools to run a code that can be hung is a questionable solution. вт, 16 мар. 2021 г. в 23:30, Alexey Kukushkin : > Pavel, > > So what you are saying is submitting a continuation to .NET Thread Pool > already respects current SynchronizationContext and ConfigureAwait. In > this case the IEP looks complete (for some reason I thought that we should > take care about the SynchronizationContext inside the Ignite.NET > implementation). > > -- > Best regards, > Alexey >
