One ThreadPool VS. many ThreadPools In a java spring boot (web) project
up vote
0
down vote
favorite
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 at 13:29
Aviad Shalom
11
New contributor
Aviad Shalom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
0
down vote
favorite
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 at 13:29
Aviad Shalom
11
New contributor
Aviad Shalom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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 at 13:56
no , only one is executable and he transitivelyusing the rest of them .
– Aviad Shalom
Nov 21 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 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 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 at 15:52
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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 at 13:29
Aviad Shalom
11
New contributor
Aviad Shalom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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 at 13:29
Aviad Shalom
11
New contributor
Aviad Shalom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Nov 21 at 13:29
Aviad Shalom
11
New contributor
Aviad Shalom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited Nov 22 at 19:02
asked Nov 21 at 13:29
Aviad Shalom
11
New contributor
Aviad Shalom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Nov 21 at 13:29
Aviad Shalom
11
asked Nov 21 at 13:29
Aviad Shalom
11
11
New contributor
Aviad Shalom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Aviad Shalom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Aviad Shalom is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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 at 13:56
no , only one is executable and he transitivelyusing the rest of them .
– Aviad Shalom
Nov 21 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 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 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 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 at 13:56
no , only one is executable and he transitivelyusing the rest of them .
– Aviad Shalom
Nov 21 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 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 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 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 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 at 13:56
no , only one is executable and he transitivelyusing the rest of them .
– Aviad Shalom
Nov 21 at 14:04
no , only one is executable and he transitivelyusing the rest of them .
– Aviad Shalom
Nov 21 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 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 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 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 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 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 at 15:52
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Aviad Shalom is a new contributor. Be nice, and check out our Code of Conduct.
Aviad Shalom is a new contributor. Be nice, and check out our Code of Conduct.
Aviad Shalom is a new contributor. Be nice, and check out our Code of Conduct.
Aviad Shalom is a new contributor. Be nice, and check out our Code of Conduct.
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 at 13:56
no , only one is executable and he transitivelyusing the rest of them .
– Aviad Shalom
Nov 21 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 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 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 at 15:52