GitHub user bgutjahr opened a pull request:
https://github.com/apache/activemq-artemis/pull/1144
ARTEMIS-1078: Improved thread pool
The improved thread pool make sure that only those threads that are
currently waiting in queue poll or take calls are considered idle and ready to
run a queued task. If not enough threads are idle, new threads will be created
- up to the maximum number.
The case where this affected is was in HA backup failover, when client
reconnect tasks went into an endless loop due to an unlimited number of
reconnect attempts, preventing the task to handle the failover from being
executed due to the missed thread creation. This fix will help as long as the
thread pool's maximum number of threads has not been reached, or some of the
currently running threads will not hang in such endless loops and can run the
failover task without significant delay. I would suggest to recheck the looping
reconnect code. Maybe it can be rewritten to submit a new task to try the next
reconnect, such that other queued tasks could also be given a chance to be
executed.
I created the fix on the 1.x branch. I guess this will also affect the
master branch.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/bgutjahr/activemq-artemis improved-thread-pool
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/1144.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1144
----
commit 07edd3968f668aacf44f8f984a2c35d98552af99
Author: Bernd Gutjahr <[email protected]>
Date: 2017-03-28T13:54:58Z
ARTEMIS-1078 Improved thread pool to consider only threads waiting for the
queue to get new tasks as idle.
The thread pool maintained a counter of active threads, but that counter
was increased too late in the beforeExecute method. Submitting a task created a
new thread. If now a second task was submitter before the new thread had
started to execute it's task, the second task was queued without creating a 2nd
thread. So the second task was only executed after the first task had been
completed - even if the thread pool's maximum number of thread had not been
reached.
This fix now only count those threads that are currently waiting in the
queue's poll or take methods as idle threads, and creates new threads unless
there are enough idle threads to pick up all queued tasks.
modified:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/ActiveMQThreadPoolExecutor.java
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
