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 <voze...@gridgain.com> wrote: > 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. > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > > > > > > >
