One ThreadPool VS. many ThreadPools In a java spring boot (web) project
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
Me and my team mates had a Design argument,regarding in which level the project should manage the amount of threads, per module? or per project? other?
we would like to hear more opinions about the issue(think about maintaince of the code,good-looking-code,risks-like future deadlock,starvation, etc..).
for the purpose of the discussion we added our own thought about pros and cons of each approach.
One ThreadPool approach - all modules in the project will be injectd with a singleton Bean of a threadpool(which will have a tight bound of the maximum thread the service will need). he will be located on the common module(see structure below).
Advantages:
-good control over the thread consumption
-reduce amount of code(the bean will be delcared once).
Disadvantages:
-not SOLID, every time one of the module needs a thread he need to go to another module(common) and change the code.
-depends on the thread pool implementation might casue starvation.
-deadlock/not enough threads to continue work if one task depends on the another And some one forgot to add threads.
(my favorite )
Per Need ThreadPool approach - all modules will be responsible of amount of thread they consume , more specificlly on the @Configuration file of each module you can see one or more threadPool bean depends on the needtype of task.
Advantages:
- flexibility in managing threads.
- control of threads on the module level.
- open-close priciple on the module level.
- no deadlock/starvation that can be caused by other module's tasks.
Disatvategs:
-less control in service level.
-many and scattered creation of threadpool Beans over all the project.
Assuming project looks like the structure below and the module depends one each other with respect to numbers(module-1 uses module-2 which uses module 3 and so on):
*module 1 is excutable.
project :
-common-module
-module-1
-module-2
-module-3
-module-4
java spring multithreading thread-safety threadpool
asked Nov 21 '18 at 13:29
Aviad ShalomAviad Shalom
11
add a comment |
Me and my team mates had a Design argument,regarding in which level the project should manage the amount of threads, per module? or per project? other?
we would like to hear more opinions about the issue(think about maintaince of the code,good-looking-code,risks-like future deadlock,starvation, etc..).
for the purpose of the discussion we added our own thought about pros and cons of each approach.
One ThreadPool approach - all modules in the project will be injectd with a singleton Bean of a threadpool(which will have a tight bound of the maximum thread the service will need). he will be located on the common module(see structure below).
Advantages:
-good control over the thread consumption
-reduce amount of code(the bean will be delcared once).
Disadvantages:
-not SOLID, every time one of the module needs a thread he need to go to another module(common) and change the code.
-depends on the thread pool implementation might casue starvation.
-deadlock/not enough threads to continue work if one task depends on the another And some one forgot to add threads.
(my favorite )
Per Need ThreadPool approach - all modules will be responsible of amount of thread they consume , more specificlly on the @Configuration file of each module you can see one or more threadPool bean depends on the needtype of task.
Advantages:
- flexibility in managing threads.
- control of threads on the module level.
- open-close priciple on the module level.
- no deadlock/starvation that can be caused by other module's tasks.
Disatvategs:
-less control in service level.
-many and scattered creation of threadpool Beans over all the project.
Assuming project looks like the structure below and the module depends one each other with respect to numbers(module-1 uses module-2 which uses module 3 and so on):
*module 1 is excutable.
project :
-common-module
-module-1
-module-2
-module-3
-module-4
java spring multithreading thread-safety threadpool
asked Nov 21 '18 at 13:29
Aviad ShalomAviad Shalom
11
Is each module a standalone executable (Über jar, war, ear)? If yes, then they will each have their own instance so the the bean could be defined in common, with configuration, such as thread count, in each module.
– Andrew S
Nov 21 '18 at 13:56
no , only one is executable and he transitivelyusing the rest of them .
– Aviad Shalom
Nov 21 '18 at 14:04
no deadlock/starvation that can be caused by other Are you sure? Could another module have a high priority thread pool which hogs the CPU under load from another module which has a normal/low priority thread pool?
– Andrew S
Nov 21 '18 at 14:21
I guess as long as the schduling mechanism of the OS works fine to unrelated threadpools(which is our case) won't effect each other..
– Aviad Shalom
Nov 21 '18 at 15:09
Why choose... Just make the thread pool (or rather theTaskExecutororExecutorService) injectable into the class that needs it. That way you can do whatever you like and delay that to configuration time. You can then give each module their own threadpool, each class or everything a single managed thread pool. Whatever you like. There is no 1 solution to fit them all, so make that a deferred choice.
– M. Deinum
Nov 21 '18 at 15:52
add a comment |
Me and my team mates had a Design argument,regarding in which level the project should manage the amount of threads, per module? or per project? other?
we would like to hear more opinions about the issue(think about maintaince of the code,good-looking-code,risks-like future deadlock,starvation, etc..).
for the purpose of the discussion we added our own thought about pros and cons of each approach.
One ThreadPool approach - all modules in the project will be injectd with a singleton Bean of a threadpool(which will have a tight bound of the maximum thread the service will need). he will be located on the common module(see structure below).
Advantages:
-good control over the thread consumption
-reduce amount of code(the bean will be delcared once).
Disadvantages:
-not SOLID, every time one of the module needs a thread he need to go to another module(common) and change the code.
-depends on the thread pool implementation might casue starvation.
-deadlock/not enough threads to continue work if one task depends on the another And some one forgot to add threads.
(my favorite )
Per Need ThreadPool approach - all modules will be responsible of amount of thread they consume , more specificlly on the @Configuration file of each module you can see one or more threadPool bean depends on the needtype of task.
Advantages:
- flexibility in managing threads.
- control of threads on the module level.
- open-close priciple on the module level.
- no deadlock/starvation that can be caused by other module's tasks.
Disatvategs:
-less control in service level.
-many and scattered creation of threadpool Beans over all the project.
Assuming project looks like the structure below and the module depends one each other with respect to numbers(module-1 uses module-2 which uses module 3 and so on):
*module 1 is excutable.
project :
-common-module
-module-1
-module-2
-module-3
-module-4
java spring multithreading thread-safety threadpool
asked Nov 21 '18 at 13:29
Aviad ShalomAviad Shalom
11
Me and my team mates had a Design argument,regarding in which level the project should manage the amount of threads, per module? or per project? other?
we would like to hear more opinions about the issue(think about maintaince of the code,good-looking-code,risks-like future deadlock,starvation, etc..).
for the purpose of the discussion we added our own thought about pros and cons of each approach.
One ThreadPool approach - all modules in the project will be injectd with a singleton Bean of a threadpool(which will have a tight bound of the maximum thread the service will need). he will be located on the common module(see structure below).
Advantages:
-good control over the thread consumption
-reduce amount of code(the bean will be delcared once).
Disadvantages:
-not SOLID, every time one of the module needs a thread he need to go to another module(common) and change the code.
-depends on the thread pool implementation might casue starvation.
-deadlock/not enough threads to continue work if one task depends on the another And some one forgot to add threads.
(my favorite )
Per Need ThreadPool approach - all modules will be responsible of amount of thread they consume , more specificlly on the @Configuration file of each module you can see one or more threadPool bean depends on the needtype of task.
Advantages:
- flexibility in managing threads.
- control of threads on the module level.
- open-close priciple on the module level.
- no deadlock/starvation that can be caused by other module's tasks.
Disatvategs:
-less control in service level.
-many and scattered creation of threadpool Beans over all the project.
Assuming project looks like the structure below and the module depends one each other with respect to numbers(module-1 uses module-2 which uses module 3 and so on):
*module 1 is excutable.
project :
-common-module
-module-1
-module-2
-module-3
-module-4
java spring multithreading thread-safety threadpool
java spring multithreading thread-safety threadpool
asked Nov 21 '18 at 13:29
Aviad ShalomAviad Shalom
11
asked Nov 21 '18 at 13:29
Aviad ShalomAviad Shalom
11
edited Nov 22 '18 at 19:02
Aviad Shalom
asked Nov 21 '18 at 13:29
Aviad ShalomAviad Shalom
11
asked Nov 21 '18 at 13:29
Aviad ShalomAviad Shalom
11
asked Nov 21 '18 at 13:29
Aviad ShalomAviad Shalom
11
11
Is each module a standalone executable (Über jar, war, ear)? If yes, then they will each have their own instance so the the bean could be defined in common, with configuration, such as thread count, in each module.
– Andrew S
Nov 21 '18 at 13:56
no , only one is executable and he transitivelyusing the rest of them .
– Aviad Shalom
Nov 21 '18 at 14:04
no deadlock/starvation that can be caused by other Are you sure? Could another module have a high priority thread pool which hogs the CPU under load from another module which has a normal/low priority thread pool?
– Andrew S
Nov 21 '18 at 14:21
I guess as long as the schduling mechanism of the OS works fine to unrelated threadpools(which is our case) won't effect each other..
– Aviad Shalom
Nov 21 '18 at 15:09
Why choose... Just make the thread pool (or rather theTaskExecutororExecutorService) injectable into the class that needs it. That way you can do whatever you like and delay that to configuration time. You can then give each module their own threadpool, each class or everything a single managed thread pool. Whatever you like. There is no 1 solution to fit them all, so make that a deferred choice.
– M. Deinum
Nov 21 '18 at 15:52
add a comment |
Is each module a standalone executable (Über jar, war, ear)? If yes, then they will each have their own instance so the the bean could be defined in common, with configuration, such as thread count, in each module.
– Andrew S
Nov 21 '18 at 13:56
no , only one is executable and he transitivelyusing the rest of them .
– Aviad Shalom
Nov 21 '18 at 14:04
no deadlock/starvation that can be caused by other Are you sure? Could another module have a high priority thread pool which hogs the CPU under load from another module which has a normal/low priority thread pool?
– Andrew S
Nov 21 '18 at 14:21
I guess as long as the schduling mechanism of the OS works fine to unrelated threadpools(which is our case) won't effect each other..
– Aviad Shalom
Nov 21 '18 at 15:09
Why choose... Just make the thread pool (or rather theTaskExecutororExecutorService) injectable into the class that needs it. That way you can do whatever you like and delay that to configuration time. You can then give each module their own threadpool, each class or everything a single managed thread pool. Whatever you like. There is no 1 solution to fit them all, so make that a deferred choice.
– M. Deinum
Nov 21 '18 at 15:52
Is each module a standalone executable (Über jar, war, ear)? If yes, then they will each have their own instance so the the bean could be defined in common, with configuration, such as thread count, in each module.
– Andrew S
Nov 21 '18 at 13:56
Is each module a standalone executable (Über jar, war, ear)? If yes, then they will each have their own instance so the the bean could be defined in common, with configuration, such as thread count, in each module.
– Andrew S
Nov 21 '18 at 13:56
no , only one is executable and he transitivelyusing the rest of them .
– Aviad Shalom
Nov 21 '18 at 14:04
no , only one is executable and he transitivelyusing the rest of them .
– Aviad Shalom
Nov 21 '18 at 14:04
no deadlock/starvation that can be caused by other Are you sure? Could another module have a high priority thread pool which hogs the CPU under load from another module which has a normal/low priority thread pool?
– Andrew S
Nov 21 '18 at 14:21
no deadlock/starvation that can be caused by other Are you sure? Could another module have a high priority thread pool which hogs the CPU under load from another module which has a normal/low priority thread pool?
– Andrew S
Nov 21 '18 at 14:21
I guess as long as the schduling mechanism of the OS works fine to unrelated threadpools(which is our case) won't effect each other..
– Aviad Shalom
Nov 21 '18 at 15:09
I guess as long as the schduling mechanism of the OS works fine to unrelated threadpools(which is our case) won't effect each other..
– Aviad Shalom
Nov 21 '18 at 15:09
Why choose... Just make the thread pool (or rather the
TaskExecutor or ExecutorService) injectable into the class that needs it. That way you can do whatever you like and delay that to configuration time. You can then give each module their own threadpool, each class or everything a single managed thread pool. Whatever you like. There is no 1 solution to fit them all, so make that a deferred choice.– M. Deinum
Nov 21 '18 at 15:52
Why choose... Just make the thread pool (or rather the
TaskExecutor or ExecutorService) injectable into the class that needs it. That way you can do whatever you like and delay that to configuration time. You can then give each module their own threadpool, each class or everything a single managed thread pool. Whatever you like. There is no 1 solution to fit them all, so make that a deferred choice.– M. Deinum
Nov 21 '18 at 15:52
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53413137%2fone-threadpool-vs-many-threadpools-in-a-java-spring-boot-web-project%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53413137%2fone-threadpool-vs-many-threadpools-in-a-java-spring-boot-web-project%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Is each module a standalone executable (Über jar, war, ear)? If yes, then they will each have their own instance so the the bean could be defined in common, with configuration, such as thread count, in each module.
– Andrew S
Nov 21 '18 at 13:56
no , only one is executable and he transitivelyusing the rest of them .
– Aviad Shalom
Nov 21 '18 at 14:04
no deadlock/starvation that can be caused by other Are you sure? Could another module have a high priority thread pool which hogs the CPU under load from another module which has a normal/low priority thread pool?
– Andrew S
Nov 21 '18 at 14:21
I guess as long as the schduling mechanism of the OS works fine to unrelated threadpools(which is our case) won't effect each other..
– Aviad Shalom
Nov 21 '18 at 15:09
Why choose... Just make the thread pool (or rather the
TaskExecutororExecutorService) injectable into the class that needs it. That way you can do whatever you like and delay that to configuration time. You can then give each module their own threadpool, each class or everything a single managed thread pool. Whatever you like. There is no 1 solution to fit them all, so make that a deferred choice.– M. Deinum
Nov 21 '18 at 15:52