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 executes another job on the same node, can we just execute it in the same thread? This seems to fix all starvation issues discussed in this thread. Am I missing something? -Val On Thu, Mar 9, 2017 at 2:32 AM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > OK, I created it: https://issues.apache.org/jira/browse/IGNITE-4802 > > -Val > > On Thu, Mar 9, 2017 at 9:58 AM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > >> Valya, >> >> Not yet. >> >> On Thu, Mar 9, 2017 at 11:50 AM, Valentin Kulichenko < >> valentin.kuliche...@gmail.com> wrote: >> >> > 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. >> > > > > >> > > > >> > > >> > >> > >
