I have a Web application where a request may invoke multiple jobs, which have to run in parallel. Jobs involve communication over the network, so they are not exactly CPU-bound; estimated duration of such job is between several seconds and several minutes.
The obvious solution is to delegate job execution to a dedicated thread pool. However I would like to avoid the situation when one client (i.e. one request) hogs most of the pool for its own jobs leaving nothing to the others. At the same time, the job-creating request should not block; it should submit its jobs for execution and immediately return. Essentially what I am looking for is the ability to set quota based on some custom criterion, so that, for example, no more than 20 matching jobs would be running at the same time, even if more have been submitted to the thread pool. Is there perhaps anything out-of-the-box for this?
Another alternative of course is to create a new fixed thread pool instance for each request, submit jobs to it and then shutdown, but it does not feel like the right way to do it.