maxJobsActive in JobWorker #133
Comments
ChrisKujawa
added a commit
that referenced
this issue
Aug 14, 2020
The worker now allows to handle jobs concurrently. Via a new configuration `HandlerThreads` you can set the thread count, which are used to handle activated jobs. Make sure your given Handler implementation is thread-safe. Per default the HandlerThread is set to 1, to be backwards compatible. Fixed some concurrency issues in activating and job handling, which caused that either for a longer time no jobs are polled or not handled or polled to fast. Poll interval are now respected better. It is rewritten in a way that it is now also better testable. Introducing an threshold activation mechanism, which means that new jobs are only activated after the working queue reaches a threshold of 0.6. **Example:** maxActivationCount = 32 threshold = Ceil(32 * 0.6) = 20 If the maxActivationCount is set to 32, then for first twelve jobs no new jobs are activated. After going under 20 jobs it will poll again for new jobs, based on the work queue (32 - work queue count). This allows to batch better job activation it will reduce the load on the gateway and broker and avoids doing to much requests for a single job activation. closes #133 closes #149
Merged
ChrisKujawa
added a commit
that referenced
this issue
Aug 15, 2020
The worker now allows to handle jobs concurrently. Via a new configuration `HandlerThreads` you can set the thread count, which are used to handle activated jobs. Make sure your given Handler implementation is thread-safe. Per default the HandlerThread is set to 1, to be backwards compatible. Fixed some concurrency issues in activating and job handling, which caused that either for a longer time no jobs are polled or not handled or polled to fast. Poll interval are now respected better. It is rewritten in a way that it is now also better testable. Introducing an threshold activation mechanism, which means that new jobs are only activated after the working queue reaches a threshold of 0.6. **Example:** maxActivationCount = 32 threshold = Ceil(32 * 0.6) = 20 If the maxActivationCount is set to 32, then for first twelve jobs no new jobs are activated. After going under 20 jobs it will poll again for new jobs, based on the work queue (32 - work queue count). This allows to batch better job activation it will reduce the load on the gateway and broker and avoids doing to much requests for a single job activation. closes #133 closes #149
ChrisKujawa
added a commit
that referenced
this issue
Aug 15, 2020
The worker now allows to handle jobs concurrently. Via a new configuration `HandlerThreads` you can set the thread count, which are used to handle activated jobs. Make sure your given Handler implementation is thread-safe. Per default the HandlerThread is set to 1, to be backwards compatible. Fixed some concurrency issues in activating and job handling, which caused that either for a longer time no jobs are polled or not handled or polled to fast. Poll interval are now respected better. It is rewritten in a way that it is now also better testable. Introducing an threshold activation mechanism, which means that new jobs are only activated after the working queue reaches a threshold of 0.6. **Example:** maxActivationCount = 32 threshold = Ceil(32 * 0.6) = 20 If the maxActivationCount is set to 32, then for first twelve jobs no new jobs are activated. After going under 20 jobs it will poll again for new jobs, based on the work queue (32 - work queue count). This allows to batch better job activation it will reduce the load on the gateway and broker and avoids doing to much requests for a single job activation. closes #133 closes #149
ChrisKujawa
added a commit
that referenced
this issue
Aug 21, 2020
The worker now allows to handle jobs concurrently. Via a new configuration `HandlerThreads` you can set the thread count, which are used to handle activated jobs. Make sure your given Handler implementation is thread-safe. Per default the HandlerThread is set to 1, to be backwards compatible. Fixed some concurrency issues in activating and job handling, which caused that either for a longer time no jobs are polled or not handled or polled to fast. Poll interval are now respected better. It is rewritten in a way that it is now also better testable. Introducing an threshold activation mechanism, which means that new jobs are only activated after the working queue reaches a threshold of 0.6. **Example:** maxActivationCount = 32 threshold = Ceil(32 * 0.6) = 20 If the maxActivationCount is set to 32, then for first twelve jobs no new jobs are activated. After going under 20 jobs it will poll again for new jobs, based on the work queue (32 - work queue count). This allows to batch better job activation it will reduce the load on the gateway and broker and avoids doing to much requests for a single job activation. closes #133 closes #149
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://github.com/zeebe-io/zeebe-client-csharp/blob/57d3ba481dc71dda6d3e90ee5d0516d2aa97e06d/Client/Impl/Worker/JobWorker.cs#L123
Now the HandleActivatedJobs handle jobs one by one, which didn't meet our expectations of MaxJobsToActivate.
The java client process active tasks concurrently
https://github.com/zeebe-io/zeebe/blob/2d53315fed41b32d7785762a9267f77cb38ba3e3/clients/java/src/main/java/io/zeebe/client/impl/worker/JobWorkerImpl.java#L122
The text was updated successfully, but these errors were encountered: