Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configurable Threadpools #22

Open
joel-bernstein opened this issue Sep 24, 2014 · 1 comment
Open

Configurable Threadpools #22

joel-bernstein opened this issue Sep 24, 2014 · 1 comment

Comments

@joel-bernstein
Copy link
Contributor

It would be great if there was a way to configure named threadpools that were managed by Heliosearch. These threadpools could then shared by features that could benefit from parallel execution.

@yonik
Copy link
Member

yonik commented Sep 24, 2014

Good idea...
One general thing to watch out for... any bounded threadpool should be thought of like a lock/semaphore. Two different modules, each with their own bounded threadpool, calling each other is a deadlock recipe. Even code that calls itself recursively (as faceting does) could deadlock with itself using a bounded threadpool.

Another related thing that would be useful: a completion service that only used N threads from a given thread pool (i.e. you have a bigger thread pool, but you don't want one request to dominate it). See PerSegmentSingleValuedFaceting

Another thought is that the size of a threadpool would often be related to maximizing throughput (i.e. for a CPU bound task, it would be related to the number of CPU cores on a box). Given that, it almost makes most sense for these threadpools to be global (on the CoreContainer, shared across all cores). I'm not sure what that means as far as configuration though.... solrconfig.xml wouldn't be the right spot for anything on CoreContainer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants