GitHub user kishoreg opened a pull request:
https://github.com/apache/helix/pull/81
Creating a separate threadpool to handle batchMessages
batchMessages were using the same threadpool as sub tasks. This works as
long the thread pool size is greater than the number of messages with
batchMessageMode=true. If not, there is a deadlock. Consider the following
scenario -
- 100 messages with batchMessage=true come in, each with 10 submessages
- let's say threadpool size is 40 (this is current default)
- 40 message will get scheduled first. Once the execution of the thread
starts, each thread now tries to execute the 10 sub-messages but in the current
code we use the same threadpool to execute batch message and sub message. This
means the sub-messages never get scheduled and everything gets blocked.
The solution was to use a separate threadpool for state transition messages
here batchMessage=true.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kishoreg/helix batch-message-bug-fix
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/helix/pull/81.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 #81
----
commit 70a585aca1302aff767a91c59040ad9c94439323
Author: kishoreg <[email protected]>
Date: 2017-04-03T07:10:20Z
Creating a separate threadpool to handle batchMessages
----
---
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.
---
