cancel
Showing results for 
Search instead for 
Did you mean: 

Job Executor Affinity/Preference

gregdavisfromnj
Champ on-the-rise
Champ on-the-rise
Is there a way to set a preference or affinity on a process to an executor, such that even if using non-exclusive continuations, a particular executor is guaranteed to process the execution?

There are a few developers on my team.  We all share a common database, which our process engines connect to.  This is preferable to us than everyone having their own database (either a DBMS server or h2).  We divide our work, and typically don't step on each other's toes, except for async continuations of process in a job executor.

For example, if I create a process in my local process engine which hits an async activity, a new execution is created in the database which a job executor on somebody else's machine typically picks up to continue.  From what I gather of exclusive continuations, the executor that picked up the execution will continue for all other async activities, unless the process is modeled to not do that.  But, and it never fails, the "wrong" executor picks up the continuation and I never hit a set breakpoint, as my teammate's job executor is continuing the process in a different JVM and different physical machine.

In a less dev/test scenario, this may be used as a priority queue for the waiting jobs in the database.  In other words, my pool of executors may not all be symmetric, and instead some may have different hardware or may be located in different geographic places to optimize latencies.  So, I may want to set of executor nodes to handle particular process definitions.  And, the affinity may be a short lived preference, so having it explicitly in a process definition is probably not what I want.

Thanks
1 REPLY 1

trademak
Star Contributor
Star Contributor
With the new async executor in 5.17 the asynchronous jobs (not timers) are executed in the same process engine where the process instance is created or the execution is executed by default. It's not using the jobs table and a polling query anymore but a thread pool. Would that work for your use case?

Best regards,