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 nodes, and in this case separate pool is the only reliable solution.
On Sat, Mar 25, 2017 at 1:50 AM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > 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. > >> > > > > > >> > > > > >> > > > >> > > >> > > > > >
