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 <dsetrak...@apache.org>
wrote:
> 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 <voze...@gridgain.com>
> wrote:
>
> > 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 this case continuations are unusable.
> >
> > More convenient approach is to map separate jobs to separate thread
> pools.
> > This technique is successfully employed in Hazelcast. You just define
> > additional executors and say that job A is to be executed one thread
> pool,
> > and job B on another.
> >
> > The same technique is applicable for services:
> >
> > class MyService implements Service {
> > @IgniteInstanceResource
> > Ignite ignite;
> >
> > void myMethod() {
> >
> > ignite.service().withExecutor("myExecutor").service("
> > myService").nestedCall();
> > }
> > }
> >
> > All in all I would do the following:
> > 1) Create separate built-in pool for services to make sure that in simple
> > cases users are able to call compute jobs from service methods.
> > 2) Implement custom executors which will be applicable for both compute
> [1]
> > and service components.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-4699
> >
> > 08 марта 2017 г. 23:01 пользователь "Dmitriy Setrakyan" <
> > dsetrak...@apache.org> написал:
> >
> > > 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.
> > >
> >
>
