Worker does not long poll correctly #149
Assignees
Labels
bug
Something isn't working
Comments
|
Could you be a bit more specific and tell me what you're observing and what would be expected. Can you reproduce it somehow? Long polling should work as far as I know. |
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
The 0.16.1 client does not long poll. It seems to do an immediate short poll, then repoll at the next poll interval.
The text was updated successfully, but these errors were encountered: