Re: Continuations for services

2017-03-28 Thread Valentin Kulichenko
Vova, Take a look at GridJobProcessor#processJobExecuteRequest method. In particular, I'm talking about this piece of code: if (ctx.localNodeId().equals(node.id())) { // Always execute in another thread for local node. executeAsync(job); // No sync execution. job = null; }

Re: Continuations for services

2017-03-28 Thread Vladimir Ozerov
Valya, Could you please point me where we delegate thread to another pool? I remember we did something around this when working with some streamer problems. On Tue, Mar 28, 2017 at 4:18 AM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Vova, > > Agree, I already merged

Re: Continuations for services

2017-03-27 Thread Valentin Kulichenko
Vova, Agree, I already merged IGNITE-4802. However, I'm still interested why we always switch to another thread when executing a job locally. Does anyone have an idea why we do this? -Val On Sat, Mar 25, 2017 at 7:22 AM, Vladimir Ozerov wrote: > Valya, > > I don't think

Re: Continuations for services

2017-03-25 Thread Vladimir Ozerov
Valya, I don't think it will resolve all the cases. For example, what if I execute remote job from another job? "Remoteness" could be caused by job natire (broadcast), specific cluster group, or affinity call/run on remote key. Also starvation is possible not only on local node, but between

Re: Continuations for services

2017-03-24 Thread Valentin Kulichenko
Folks, I tend to think that a separate pool for services is not right solution. We currently execute any new compute job in a separate thread, even if we're already in the public pool (see code in GridJobProcessor#processJobExecuteRequest). What is the reason for this? When a job synchronously

Re: Continuations for services

2017-03-09 Thread Valentin Kulichenko
OK, I created it: https://issues.apache.org/jira/browse/IGNITE-4802 -Val On Thu, Mar 9, 2017 at 9:58 AM, Vladimir Ozerov wrote: > Valya, > > Not yet. > > On Thu, Mar 9, 2017 at 11:50 AM, Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > > > Vladimir, > > > >

Re: Continuations for services

2017-03-09 Thread Valentin Kulichenko
Vladimir, This makes sense to me. Is there a ticket for separate thread pool for services? -Val On Thu, Mar 9, 2017 at 2:52 AM, Dmitriy Setrakyan wrote: > Vladimr, it sounds like what you are suggesting is allowing users specify > named executors in configuration and

Re: Continuations for services

2017-03-08 Thread Dmitriy Setrakyan
Vladimr, it sounds like what you are suggesting is allowing users specify named executors in configuration and then use them from code, right? I think I like this idea very much. On Wed, Mar 8, 2017 at 1:46 PM, Vladimir Ozerov wrote: > Continuations is not very good idea.

Re: Continuations for services

2017-03-08 Thread Vladimir Ozerov
Continuations is not very good idea. It is useful if user has simple logic when one job calls another from within the same execute/run/call method. But if you have complex logic with OOP abstractions and reusable components, nested job call can be located many stack frames down from parent job. In

Re: Continuations for services

2017-03-08 Thread Dmitriy Setrakyan
On Wed, Mar 8, 2017 at 11:58 AM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Separate thread pool will not solve the case of calling a service from > another service. > Why not? The caller thread should block.

Re: Continuations for services

2017-03-08 Thread Valentin Kulichenko
Separate thread pool will not solve the case of calling a service from another service. -Val On Wed, Mar 8, 2017 at 8:38 PM, Dmitriy Setrakyan wrote: > On Wed, Mar 8, 2017 at 11:36 AM, Vladimir Ozerov > wrote: > > > Val, > > > > Don't panic! :) I

Re: Continuations for services

2017-03-08 Thread Vladimir Ozerov
Val, Don't panic! :) I created a ticket for custom thread pools for compute tasks recently. Probably it can help us with services as well. 08 марта 2017 г. 22:15 пользователь "Dmitriy Setrakyan" < dsetrak...@apache.org> написал: How about deploying services in their own thread pools? On Wed,

Re: Continuations for services

2017-03-08 Thread Dmitriy Setrakyan
How about deploying services in their own thread pools? On Wed, Mar 8, 2017 at 2:05 AM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Igniters, > > I recently realized that we have serious architectural flow in Service > Grid. The problem is services are executed in public thread

Continuations for services

2017-03-08 Thread Valentin Kulichenko
Igniters, I recently realized that we have serious architectural flow in Service Grid. The problem is services are executed in public thread pool, which means that user can't: - synchronously invoke service from another service - synchronously invoke task/closure from service In Compute Grid we