Re: Significant Items to Tackle
On further look, this looks interesting and I am happy to dive into the spring framework. Please help me in getting started On Mon, 29 Mar 2021, 11:49 Atri Sharma, wrote: > Thanks Sam and Ivan. > > I am happy to look into that but it looks like most of the work is done > there? > > Also, is there something in core that I can pickup as well? > > > On Mon, 29 Mar 2021, 03:20 Ivan Pavlukhin, wrote: > >> Gmail treated last message as spam. Bumping. >> >> 2021-03-28 16:05 GMT+03:00, Данилов Семён : >> > Hello Atri! >> > >> > Would you like to contribute into Ignite Spring integrations? You can >> take a >> > look at this particular jira filter: >> > >> https://issues.apache.org/jira/browse/IGNITE-9524?jql=project%20%3D%20Ignite%20and%20summary%20~%20%22spring%22%20and%20status%20not%20in%20(Resolved%2C%20Closed) >> > . >> > Personally, I think one of the most valuable issues there is >> > https://issues.apache.org/jira/browse/IGNITE-9524. I have a lot of >> > experience with Spring, so you can reach out to me if you have any >> > questions. >> > >> > Cheers, Sam. >> > >> > 25.03.2021, 23:33, "Atri Sharma" : >> >> Hi Community, >> >> >> >> First off, I want to thank the community for being so welcoming and >> >> helpful. This is an awesome place to be in. >> >> >> >> Now that I have worked on some issues, I would like to get my hands >> >> deeper >> >> and with larger issues in the core. Also, some more intermediate >> tickets >> >> to >> >> tackle, my queue has gotten empty :) >> >> >> >> Please help and advice. >> >> >> >> Regards, >> >> >> >> Atri >> > >> >> >> -- >> >> Best regards, >> Ivan Pavlukhin >> >
Re: IEP-70: Async Continuation Executor
But what if I need to have exactly one callback synchronous, and all other can
be asynchronous?
I would separate two cases: an existing user who wants their old behavior back,
and a new user that wants to fine tune their app.
The existing user needs a global "make it all synchronous" switch.
The new user should only enable the fast-but-dangerous behavior locally,
exactly where they need it.
In my ideal world, the users don't configure thread pools, they just have safe
default behavior (async execution)
and a way to make it fast for one particular function (with annotation or
anything else).
Also, this should work in a similar way for different APIs - so I'm trying to
lay some basis to rework all of these continuous queries and event listeners,
even though they're explicitly mentioned as out of scope for IEP-70.
At the same time, I understand that any change we make now will have pros and
cons, and we can't make it perfect because of compatibility reasons.
I'm OK to proceed with the approach you're suggesting if I haven't convinced
you by now :)
Thanks,
Stan
> On 29 Mar 2021, at 22:47, Pavel Tupitsyn wrote:
>
> Stan,
>
> Unfortunately, annotations have a few drawbacks:
> * Can't configure it globally ("I already use sync callbacks, give me back
> the old behavior in one line")
> * Can't configure in Spring
> * Useless in C++ & .NET
> * You can already specify executor in IgniteFuture#listenAsync, so there
> seems to be no added value
>
>> the only value we really expect the user to set in that property is
> Runnable::run
> Not really - there are lots of available options [1].
> Some apps may already have one or more thread pools that can be used for
> continuations.
>
>> you can't specify Runnable::run in a Spring XML
> Good point, but creating a class for that is trivial.
> We can ship a ready-made class and mention it in the docs for simplicity.
>
>
> Globally configurable Executor fits nicely with
> existing IgniteFuture#listenAsync,
> not sure why you dislike it.
>
>
> [1]
> https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html
>
> On Mon, Mar 29, 2021 at 10:23 PM Stanislav Lukyanov
> wrote:
>
>> Thought about this some more.
>>
>> I agree that we need to be able to switch to synchronous listeners when
>> it's critical for performance.
>> However, I don't like to introduce an Executor property for that. In fact,
>> the only value
>> we really expect the user to set in that property is Runnable::run - seems
>> to be an overkill to have accept an Executor for that.
>> Furthermore, you can't specify Runnable::run in a Spring XML, can you?
>>
>> I'm thinking that maybe we should go the annotation route here.
>> Let's introduce an annotation @IgniteSyncCallback. It's the same as
>> @IgniteAsyncCallback but reverse :)
>> If a listener is annotated like that then we execute it in the same
>> thread; by default, we execute in the public pool.
>> We can also reuse the same annotation for all other callbacks we have in
>> the system - right now, the callbacks are a mix of sync and async behavior,
>> and we could transition all APIs to use async by default and enforce sync
>> callbacks when the annotation is used.
>> @IgniteAsyncCallback should eventually be deprecated.
>>
>> WDYT?
>>
>> Thanks,
>> Stan
>>
>>> On 29 Mar 2021, at 14:09, Pavel Tupitsyn wrote:
>>>
>>> Stan,
>>>
>>> I'm ok with using public pool by default, but we need a way to restore
>> the
>>> old behavior, do you agree?
>>> I think we should keep the new IgniteConfiguration property.
>>>
>>> On Fri, Mar 26, 2021 at 2:12 PM Alexei Scherbakov <
>>> alexey.scherbak...@gmail.com> wrote:
>>>
Pavel,
Dedicated pool looks safer and more manageable to me. Make sure the
>> threads
in the pool are lazily started and stopped if not used for some time.
Because I have no more real arguments against the change, I suggest to
proceed with this approach.
чт, 25 мар. 2021 г. в 22:16, Pavel Tupitsyn :
> Alexei,
>
>> we already have ways to control a listener's behavior
> No, we don't have a way to fix current broken and dangerous behavior
> globally.
> You should not expect the user to fix every async call manually.
>
>> commonPool can alter existing deployments in unpredictable ways,
>> if commonPool is heavily used for other purposes
> Common pool resizes dynamically to accommodate the load [1]
> What do you think about Stan's suggestion to use our public pool
>> instead?
>
> [1]
>
>
>> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html
>
> On Thu, Mar 25, 2021 at 10:10 PM Pavel Tupitsyn
> wrote:
>
>>> I don't agree that the code isn't related to Ignite - it is something
>> that the user does via Ignite API
>>
>> This is a misconception. When you write general-purpose async code, it
>> looks like this:
>>
Re: IEP-70: Async Continuation Executor
Stan,
Unfortunately, annotations have a few drawbacks:
* Can't configure it globally ("I already use sync callbacks, give me back
the old behavior in one line")
* Can't configure in Spring
* Useless in C++ & .NET
* You can already specify executor in IgniteFuture#listenAsync, so there
seems to be no added value
> the only value we really expect the user to set in that property is
Runnable::run
Not really - there are lots of available options [1].
Some apps may already have one or more thread pools that can be used for
continuations.
> you can't specify Runnable::run in a Spring XML
Good point, but creating a class for that is trivial.
We can ship a ready-made class and mention it in the docs for simplicity.
Globally configurable Executor fits nicely with
existing IgniteFuture#listenAsync,
not sure why you dislike it.
[1]
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html
On Mon, Mar 29, 2021 at 10:23 PM Stanislav Lukyanov
wrote:
> Thought about this some more.
>
> I agree that we need to be able to switch to synchronous listeners when
> it's critical for performance.
> However, I don't like to introduce an Executor property for that. In fact,
> the only value
> we really expect the user to set in that property is Runnable::run - seems
> to be an overkill to have accept an Executor for that.
> Furthermore, you can't specify Runnable::run in a Spring XML, can you?
>
> I'm thinking that maybe we should go the annotation route here.
> Let's introduce an annotation @IgniteSyncCallback. It's the same as
> @IgniteAsyncCallback but reverse :)
> If a listener is annotated like that then we execute it in the same
> thread; by default, we execute in the public pool.
> We can also reuse the same annotation for all other callbacks we have in
> the system - right now, the callbacks are a mix of sync and async behavior,
> and we could transition all APIs to use async by default and enforce sync
> callbacks when the annotation is used.
> @IgniteAsyncCallback should eventually be deprecated.
>
> WDYT?
>
> Thanks,
> Stan
>
> > On 29 Mar 2021, at 14:09, Pavel Tupitsyn wrote:
> >
> > Stan,
> >
> > I'm ok with using public pool by default, but we need a way to restore
> the
> > old behavior, do you agree?
> > I think we should keep the new IgniteConfiguration property.
> >
> > On Fri, Mar 26, 2021 at 2:12 PM Alexei Scherbakov <
> > alexey.scherbak...@gmail.com> wrote:
> >
> >> Pavel,
> >>
> >> Dedicated pool looks safer and more manageable to me. Make sure the
> threads
> >> in the pool are lazily started and stopped if not used for some time.
> >>
> >> Because I have no more real arguments against the change, I suggest to
> >> proceed with this approach.
> >>
> >> чт, 25 мар. 2021 г. в 22:16, Pavel Tupitsyn :
> >>
> >>> Alexei,
> >>>
> we already have ways to control a listener's behavior
> >>> No, we don't have a way to fix current broken and dangerous behavior
> >>> globally.
> >>> You should not expect the user to fix every async call manually.
> >>>
> commonPool can alter existing deployments in unpredictable ways,
> if commonPool is heavily used for other purposes
> >>> Common pool resizes dynamically to accommodate the load [1]
> >>> What do you think about Stan's suggestion to use our public pool
> instead?
> >>>
> >>> [1]
> >>>
> >>>
> >>
> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html
> >>>
> >>> On Thu, Mar 25, 2021 at 10:10 PM Pavel Tupitsyn
> >>> wrote:
> >>>
> > I don't agree that the code isn't related to Ignite - it is something
> that the user does via Ignite API
>
> This is a misconception. When you write general-purpose async code, it
> looks like this:
>
> myClass.fooAsync()
> .chain(igniteCache.putAsync)
> .chain(myClass.barAsync)
> .chain(...)
>
> And so on, you jump from one continuation to another.
> You don't think about this as "I use Ignite API to run my
> >> continuation",
> this is just another async call among hundreds of others.
>
> And you don't want 1 of 20 libraries that you use to have "special
> >> needs"
> like Ignite does right now.
>
> I know Java is late to the async party and not everyone is used to
> this
> mindset,
> but the situation changes, more and more code bases go async all the
> >> way,
> use CompletionStage everywhere, etc.
>
>
> > If we go with the public pool - no additional options needed.
>
> I guess public pool should work.
> However, I would prefer to keep using commonPool, which is recommended
> >>> for
> a general purpose like this.
>
> On Thu, Mar 25, 2021 at 3:56 PM Alexei Scherbakov <
> alexey.scherbak...@gmail.com> wrote:
>
> > Pavel,
> >
> > The change still looks a bit risky to me, because the default
> executor
> >>> is
> > set to commonPool and can alter existing deployments in unpredictable
>
Re: IEP-70: Async Continuation Executor
Thought about this some more. I agree that we need to be able to switch to synchronous listeners when it's critical for performance. However, I don't like to introduce an Executor property for that. In fact, the only value we really expect the user to set in that property is Runnable::run - seems to be an overkill to have accept an Executor for that. Furthermore, you can't specify Runnable::run in a Spring XML, can you? I'm thinking that maybe we should go the annotation route here. Let's introduce an annotation @IgniteSyncCallback. It's the same as @IgniteAsyncCallback but reverse :) If a listener is annotated like that then we execute it in the same thread; by default, we execute in the public pool. We can also reuse the same annotation for all other callbacks we have in the system - right now, the callbacks are a mix of sync and async behavior, and we could transition all APIs to use async by default and enforce sync callbacks when the annotation is used. @IgniteAsyncCallback should eventually be deprecated. WDYT? Thanks, Stan > On 29 Mar 2021, at 14:09, Pavel Tupitsyn wrote: > > Stan, > > I'm ok with using public pool by default, but we need a way to restore the > old behavior, do you agree? > I think we should keep the new IgniteConfiguration property. > > On Fri, Mar 26, 2021 at 2:12 PM Alexei Scherbakov < > alexey.scherbak...@gmail.com> wrote: > >> Pavel, >> >> Dedicated pool looks safer and more manageable to me. Make sure the threads >> in the pool are lazily started and stopped if not used for some time. >> >> Because I have no more real arguments against the change, I suggest to >> proceed with this approach. >> >> чт, 25 мар. 2021 г. в 22:16, Pavel Tupitsyn : >> >>> Alexei, >>> we already have ways to control a listener's behavior >>> No, we don't have a way to fix current broken and dangerous behavior >>> globally. >>> You should not expect the user to fix every async call manually. >>> commonPool can alter existing deployments in unpredictable ways, if commonPool is heavily used for other purposes >>> Common pool resizes dynamically to accommodate the load [1] >>> What do you think about Stan's suggestion to use our public pool instead? >>> >>> [1] >>> >>> >> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html >>> >>> On Thu, Mar 25, 2021 at 10:10 PM Pavel Tupitsyn >>> wrote: >>> > I don't agree that the code isn't related to Ignite - it is something that the user does via Ignite API This is a misconception. When you write general-purpose async code, it looks like this: myClass.fooAsync() .chain(igniteCache.putAsync) .chain(myClass.barAsync) .chain(...) And so on, you jump from one continuation to another. You don't think about this as "I use Ignite API to run my >> continuation", this is just another async call among hundreds of others. And you don't want 1 of 20 libraries that you use to have "special >> needs" like Ignite does right now. I know Java is late to the async party and not everyone is used to this mindset, but the situation changes, more and more code bases go async all the >> way, use CompletionStage everywhere, etc. > If we go with the public pool - no additional options needed. I guess public pool should work. However, I would prefer to keep using commonPool, which is recommended >>> for a general purpose like this. On Thu, Mar 25, 2021 at 3:56 PM Alexei Scherbakov < alexey.scherbak...@gmail.com> wrote: > Pavel, > > The change still looks a bit risky to me, because the default executor >>> is > set to commonPool and can alter existing deployments in unpredictable > ways, > if commonPool is heavily used for other purposes. > > Runnable::run usage is not obvious as well and should be properly > documented as a way to return to old behavior. > > I'm not sure we need it in 2.X for the reasons above - we already have > ways > to control a listener's behavior - it's a matter of good documentation >>> to > me. > > > > > > > чт, 25 мар. 2021 г. в 15:33, Pavel Tupitsyn : > >> Alexei, >> >>> Sometimes it's more desirable to execute the listener in the same > thread >>> It's up to the user to decide. >> >> Yes, we give users a choice to configure the executor as >> Runnable::run > and >> use the same thread if needed. >> However, it should not be the default behavior as explained above >> (bad >> usability, unexpected major issues). >> >> On Thu, Mar 25, 2021 at 3:06 PM Alexei Scherbakov < >> alexey.scherbak...@gmail.com> wrote: >> >>> Pavel, >>> >>> While I understand the issue and overall agree with you, I'm >> against > the >>> execution of listeners in
[jira] [Created] (IGNITE-14440) Run external tests in ducktape
Maksim Timonin created IGNITE-14440: --- Summary: Run external tests in ducktape Key: IGNITE-14440 URL: https://issues.apache.org/jira/browse/IGNITE-14440 Project: Ignite Issue Type: New Feature Reporter: Maksim Timonin Docker with ducktape should have following volumes: # ignite-dev -> Ignite current branch # ignite-lib -> python lib + java deps in modules/ducktests/tests/ignitetest # ignite-tests -> python tests, default - modules/ducktests/ignitetest/tests # ignite-specs -> specs for tests, structure of directories contain specs (incl. jinja2 templates) should be redefined. Set default value for new directory within ignitetest. # /opt/ignite-* - all distributives. Mount with python libs (lib, tests, specs) must be installed in docker as develop lib (see, python setup.py develop). Notes: # Ordering of installing matters - lib, specs, tests # ignitetest - Manifest.in should skip directories: ./tests, with specs. There should be an util that responsible for uploading ignite dists. Note: # Provide a migration mode for the util. Try copy distributives from existing docker image to local fs to skip downloading them from Internet. # Download new versions by running .sh command. *Nice to have:* replace runtests.sh and ducker-ignite with: # docker-compose.yml describes num of containers, mounts, ports, etc. # entrypoint for docker is a ducktape command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14439) NPE when accessing clustername before first exchange finished
Pavel Vinokurov created IGNITE-14439: Summary: NPE when accessing clustername before first exchange finished Key: IGNITE-14439 URL: https://issues.apache.org/jira/browse/IGNITE-14439 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.9 Reporter: Pavel Vinokurov [IGNITE-11406|https://issues.apache.org/jira/browse/IGNITE-11406] has not been fixed properly for two reasons. The first is one is that _GridCacheProcessor.utilityCache_ could be accessed before the first exchange finished. The second is that it doesn't resolve the original issue, because _GridServiceProcessor.onKernelStop_ is followed by _GridCacheProcessor.onKernelStop_, so caches should be already initialized. Thus that fix should be reverted. Revering this fix induces the issue related to accessing the utility cache by getting cluster name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Azure Cloud IP Finder
Hello! I have left some more comments after trying this change on a real Azure cluster. Regards, -- Ilya Kasnacheev вт, 23 мар. 2021 г. в 18:32, Atri Sharma : > Thank you! > > I have updated the PR. Please see and let me know. > > On Tue, Mar 23, 2021 at 4:27 PM Ilya Kasnacheev > wrote: > > > > Hello! > > > > I am going to check this change out when I have time, using my Azure > > account. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > вт, 23 мар. 2021 г. в 07:20, Atri Sharma : > > > > > Gentle reminder on this -- please help in reviewing this. > > > > > > On Fri, Mar 19, 2021 at 10:23 AM Atri Sharma wrote: > > > > > > > > Thanks Denis. > > > > > > > > I have raised a PR for the same: > > > > > > > > https://github.com/apache/ignite/pull/8897 > > > > > > > > Regards, > > > > > > > > Atri > > > > > > > > On Wed, Mar 10, 2021 at 1:21 AM Denis Magda > wrote: > > > > > > > > > > Atri, > > > > > > > > > > Let's discuss the subj together with the community. Ignite already > > > supports > > > > > AWS [1] and GCE [2] IP Finders out of the box, but the Azure one is > > > still > > > > > missing. I can confirm that the demand exists, and rather > frequently, > > > I see > > > > > developers asking for an Azure-native IP finder for Ignite. > > > > > > > > > > Atri, could you please research how to implement the IP finder and > > > suggest > > > > > a solution in this discussion thread? See how it was done for AWS > and > > > GCE, > > > > > we might go the same route or use a more contemporary and > > > easy-to-configure > > > > > approach for Azure. > > > > > > > > > > [1] > > > > > > > > > https://ignite.apache.org/docs/latest/clustering/discovery-in-the-cloud#amazon-s3-ip-finder > > > > > [2] > > > > > > > > > https://ignite.apache.org/docs/latest/clustering/discovery-in-the-cloud#google-compute-discovery > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > > -- > > > > Regards, > > > > > > > > Atri > > > > Apache Concerted > > > > > > > > > > > > -- > > > Regards, > > > > > > Atri > > > Apache Concerted > > > > > -- > Regards, > > Atri > Apache Concerted >
[jira] [Created] (IGNITE-14438) Add README.md files to cli and cli-common modules
Kirill Gusakov created IGNITE-14438: --- Summary: Add README.md files to cli and cli-common modules Key: IGNITE-14438 URL: https://issues.apache.org/jira/browse/IGNITE-14438 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov Assignee: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Сonnect a thin client to all nodes in the cluster
Hello,
Please pass all known server node addresses to
ClientConfiguration.setAddresses.
E.g. if everything is on one machine, for 3 servers it'll be
setAddresses("127.0.0.1:10800", "127.0.0.1:10801", "127.0.0.1:10802")
On Mon, Mar 29, 2021 at 3:23 PM Максим Плотников
wrote:
> Hello!
>
>
>
> I'm dealing with Apache Ignite at the moment. I create a thin client and
> specify for it address(host + port), user and password.
>
>
> I start 3 nodes with the following configuration:
>
>
>
>
>
> http://www.springframework.org/schema/beans;
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>
>xsi:schemaLocation="
>
> http://www.springframework.org/schema/beans
>
> http://www.springframework.org/schema/beans/spring-beans.xsd;>
>
>class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
>
>
>
>
>
>
>
>
>
>
>
> class="org.apache.ignite.configuration.ClientConnectorConfiguration">
>
> value="127.0.0.1"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
>
>
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder">
>
>
>
>
>
>
>
> 127.0.0.1:47500..47502
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The application successfully connects to the cluster, but if you
> disconnect the first coordinator node to which the application connected,
> the application loses its connection to the cluster. The 2 remaining nodes
> continue to work, but the application can no longer access them.
>
>
>
> What needs to be done for the application to continue working with the
> remaining nodes in the cluster?
>
[jira] [Created] (IGNITE-14437) Adjust test params: exclude input net failures with disabled connRecovery
Vladimir Steshin created IGNITE-14437: - Summary: Adjust test params: exclude input net failures with disabled connRecovery Key: IGNITE-14437 URL: https://issues.apache.org/jira/browse/IGNITE-14437 Project: Ignite Issue Type: Sub-task Reporter: Vladimir Steshin Assignee: Vladimir Steshin -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: IEP-70: Async Continuation Executor
Stan, I'm ok with using public pool by default, but we need a way to restore the old behavior, do you agree? I think we should keep the new IgniteConfiguration property. On Fri, Mar 26, 2021 at 2:12 PM Alexei Scherbakov < alexey.scherbak...@gmail.com> wrote: > Pavel, > > Dedicated pool looks safer and more manageable to me. Make sure the threads > in the pool are lazily started and stopped if not used for some time. > > Because I have no more real arguments against the change, I suggest to > proceed with this approach. > > чт, 25 мар. 2021 г. в 22:16, Pavel Tupitsyn : > > > Alexei, > > > > > we already have ways to control a listener's behavior > > No, we don't have a way to fix current broken and dangerous behavior > > globally. > > You should not expect the user to fix every async call manually. > > > > > commonPool can alter existing deployments in unpredictable ways, > > > if commonPool is heavily used for other purposes > > Common pool resizes dynamically to accommodate the load [1] > > What do you think about Stan's suggestion to use our public pool instead? > > > > [1] > > > > > https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html > > > > On Thu, Mar 25, 2021 at 10:10 PM Pavel Tupitsyn > > wrote: > > > > > > I don't agree that the code isn't related to Ignite - it is something > > > that the user does via Ignite API > > > > > > This is a misconception. When you write general-purpose async code, it > > > looks like this: > > > > > > myClass.fooAsync() > > > .chain(igniteCache.putAsync) > > > .chain(myClass.barAsync) > > > .chain(...) > > > > > > And so on, you jump from one continuation to another. > > > You don't think about this as "I use Ignite API to run my > continuation", > > > this is just another async call among hundreds of others. > > > > > > And you don't want 1 of 20 libraries that you use to have "special > needs" > > > like Ignite does right now. > > > > > > I know Java is late to the async party and not everyone is used to this > > > mindset, > > > but the situation changes, more and more code bases go async all the > way, > > > use CompletionStage everywhere, etc. > > > > > > > > > > If we go with the public pool - no additional options needed. > > > > > > I guess public pool should work. > > > However, I would prefer to keep using commonPool, which is recommended > > for > > > a general purpose like this. > > > > > > On Thu, Mar 25, 2021 at 3:56 PM Alexei Scherbakov < > > > alexey.scherbak...@gmail.com> wrote: > > > > > >> Pavel, > > >> > > >> The change still looks a bit risky to me, because the default executor > > is > > >> set to commonPool and can alter existing deployments in unpredictable > > >> ways, > > >> if commonPool is heavily used for other purposes. > > >> > > >> Runnable::run usage is not obvious as well and should be properly > > >> documented as a way to return to old behavior. > > >> > > >> I'm not sure we need it in 2.X for the reasons above - we already have > > >> ways > > >> to control a listener's behavior - it's a matter of good documentation > > to > > >> me. > > >> > > >> > > >> > > >> > > >> > > >> > > >> чт, 25 мар. 2021 г. в 15:33, Pavel Tupitsyn : > > >> > > >> > Alexei, > > >> > > > >> > > Sometimes it's more desirable to execute the listener in the same > > >> thread > > >> > > It's up to the user to decide. > > >> > > > >> > Yes, we give users a choice to configure the executor as > Runnable::run > > >> and > > >> > use the same thread if needed. > > >> > However, it should not be the default behavior as explained above > (bad > > >> > usability, unexpected major issues). > > >> > > > >> > On Thu, Mar 25, 2021 at 3:06 PM Alexei Scherbakov < > > >> > alexey.scherbak...@gmail.com> wrote: > > >> > > > >> > > Pavel, > > >> > > > > >> > > While I understand the issue and overall agree with you, I'm > against > > >> the > > >> > > execution of listeners in separate thread pool by default. > > >> > > > > >> > > Sometimes it's more desirable to execute the listener in the same > > >> thread, > > >> > > for example if it's some lightweight closure. > > >> > > > > >> > > It's up to the user to decide. > > >> > > > > >> > > I think the IgniteFuture.listen method should be properly > documented > > >> to > > >> > > avoid execution of cluster operations or any other potentially > > >> blocking > > >> > > operations inside the listener. > > >> > > > > >> > > Otherwise listenAsync should be used. > > >> > > > > >> > > > > >> > > > > >> > > чт, 25 мар. 2021 г. в 14:04, Pavel Tupitsyn >: > > >> > > > > >> > > > Stan, > > >> > > > > > >> > > > We have thread pools dedicated for specific purposes, like cache > > >> > > (striped), > > >> > > > compute (pub), query, etc > > >> > > > As I understand it, the reason here is to limit the number of > > >> threads > > >> > > > dedicated to a given subsystem. > > >> > > > For example, Compute may be overloaded with work, but Cache and > > >> > Discovery > > >> > > > will keep going. > > >> > >
[jira] [Created] (IGNITE-14436) Scala documentation
Thibaud Faurie created IGNITE-14436: --- Summary: Scala documentation Key: IGNITE-14436 URL: https://issues.apache.org/jira/browse/IGNITE-14436 Project: Ignite Issue Type: Bug Components: website Affects Versions: 2.9.1 Environment: Browser used : Brave (Chromium) Reporter: Thibaud Faurie Scala documentation on website is broken. When I go to [https://ignite.apache.org/releases/latest/scaladoc/] I get a ERR_TOO_MANY_REDIRECTS error. Thus can't access the doc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14435) Refactor PdsConsistentIdProcessor for reusage
Nikolay Izhikov created IGNITE-14435:
Summary: Refactor PdsConsistentIdProcessor for reusage
Key: IGNITE-14435
URL: https://issues.apache.org/jira/browse/IGNITE-14435
Project: Ignite
Issue Type: Improvement
Reporter: Nikolay Izhikov
Logic to resolve PDS folders should be reused inside {{IgniteCDC}} to lock
specific Ignite node CDC folder.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Significant Items to Tackle
Thanks Sam and Ivan. I am happy to look into that but it looks like most of the work is done there? Also, is there something in core that I can pickup as well? On Mon, 29 Mar 2021, 03:20 Ivan Pavlukhin, wrote: > Gmail treated last message as spam. Bumping. > > 2021-03-28 16:05 GMT+03:00, Данилов Семён : > > Hello Atri! > > > > Would you like to contribute into Ignite Spring integrations? You can > take a > > look at this particular jira filter: > > > https://issues.apache.org/jira/browse/IGNITE-9524?jql=project%20%3D%20Ignite%20and%20summary%20~%20%22spring%22%20and%20status%20not%20in%20(Resolved%2C%20Closed) > > . > > Personally, I think one of the most valuable issues there is > > https://issues.apache.org/jira/browse/IGNITE-9524. I have a lot of > > experience with Spring, so you can reach out to me if you have any > > questions. > > > > Cheers, Sam. > > > > 25.03.2021, 23:33, "Atri Sharma" : > >> Hi Community, > >> > >> First off, I want to thank the community for being so welcoming and > >> helpful. This is an awesome place to be in. > >> > >> Now that I have worked on some issues, I would like to get my hands > >> deeper > >> and with larger issues in the core. Also, some more intermediate tickets > >> to > >> tackle, my queue has gotten empty :) > >> > >> Please help and advice. > >> > >> Regards, > >> > >> Atri > > > > > -- > > Best regards, > Ivan Pavlukhin >
Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.
Val,
There were enough hype around Reactive programming past years. I
remind a lot of talks about RxJava. And I suppose it worth to consider
it. But it requires some time to study modern trends to make a choice.
So far I am not ready to facilitate Reactive API for Ignite 3.
Regarding CompletableFuture.
> The point is that currently a future returned from any of Ignite's async
> operations is supposed to be completed with a value only by Ignite itself,
> not by the user. If we follow the same approach in Ignite 3, returning
> CompletableFuture is surely wrong in my view.
My first thoughts was similar. But later I thought what a user would
like do with returned future. And one of cases I imagined was a case
of alternative result. E.g. a user uses Ignite and another data source
in his application. He wants to use a value arrived faster. He
combines 2 futures like CompletableFuture.anyOf(...). Consequently
even if we prohibit CompletableFuture.complete(...) explicitly then it
will be possible to create a combination that will allow premature
future completion. After all generally CompletableFuture is a
placeholder for async computaion result and if a user wants to
substitute result returned from Ignite why should we disallow him to
do it?
Also I found one more suspicious thing with CompletableFuture. As it
is a concrete class it implements a cancel() method. And as I see the
implementation does not try to cancel underlying computations. Is not
it a problem?
2021-03-29 7:30 GMT+03:00, Valentin Kulichenko :
> Ivan,
>
> It's not really about the "harm", but more about "what should we do if this
> method is called?". Imagine the following code:
>
> CompletableFuture fut = cache.getAsync(key);
> fut.complete("something");
>
> What should happen in this case?
>
> The point is that currently a future returned from any of Ignite's async
> operations is supposed to be completed with a value only by Ignite itself,
> not by the user. If we follow the same approach in Ignite 3, returning
> CompletableFuture is surely wrong in my view.
>
> At the same time, if we take a fundamentally different route with the async
> APIs, this whole discussion might become irrelevant. For example, can you
> elaborate on your thinking around the reactive API? Do you have any
> specifics in mind?
>
> -Val
>
> On Sat, Mar 27, 2021 at 9:18 PM Ivan Pavlukhin wrote:
>
>> > The methods below shouldn't be accessible for user:
>> > complete()
>> > completeExceptionaly()
>>
>> Folks, in case of user-facing API, do you think there is a real harm
>> in allowing a user to manually "complete" a future? I suppose a user
>> employs some post-processing for future results and potentially wants
>> to have control of these results as well. E.g. premature completion in
>> case when a result is no longer needed is possible usage.
>>
>> Also I thinkg it might be a good time to ponder about Future/Promise
>> APIs in general. Why such API is our choice? Can we choose e.g.
>> Reactive API style instead?
>>
>> 2021-03-27 0:33 GMT+03:00, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>> > Andrey,
>> >
>> > I see. So in a nutshell, you're saying that we want to return a future
>> that
>> > the user's code is not allowed to complete. In this case, I think it's
>> > clear that CompletableFuture is not what we need. We actually need a
>> > NonCompletableFuture :)
>> >
>> > My vote is for the custom interface.
>> >
>> > -Val
>> >
>> > On Fri, Mar 26, 2021 at 2:25 AM Andrey Mashenkov
>> >
>> > wrote:
>> >
>> >> Val,
>> >>
>> >> The methods below shouldn't be accessible for user:
>> >> complete()
>> >> completeExceptionaly()
>> >>
>> >> Returning CompletableFuture we must always make a copy to prevent the
>> >> original future from being completed by mistake.
>> >> I think it will NOT be enough to do that returing the future to the
>> >> end-user, but from every critical module to the outside of the module,
>> >> e.g. to plugins. The impact of disclosing ExchangeFuture,
>> >> PartitionReleaseFuture to plugins may be serious.
>> >>
>> >> IgniteFuture extends Future, CompletionStage which
>> >> implementation
>> >> will just wrap CompletableFuture these issues will be resolved in
>> natural
>> >> way.
>> >> In addition we can force toCompletableFuture() method to return a
>> >> defensive
>> >> copy(), that resolves the last concern.
>> >>
>> >>
>> >> On Fri, Mar 26, 2021 at 11:38 AM Konstantin Orlov
>> >>
>> >> wrote:
>> >>
>> >> > CompletableFuture seems a better option to me.
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Konstantin Orlov
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > > On 26 Mar 2021, at 11:07, Pavel Tupitsyn
>> >> > > wrote:
>> >> > >
>> >> > > On the one hand, I agree with Alexey.
>> >> > > CompletableFuture has complete* methods which should not be
>> available
>> >> to
>> >> > > the user code.
>> >> > > This can be solved with a simple interface like we do in Thin
>> Client:
>> >> > > IgniteClientFuture extends Future, CompletionStage
>> >>
