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;
}
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
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
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
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
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,
> >
> >
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
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.
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
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.
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
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,
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
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
14 matches
Mail list logo