Tomcat on Elastic Beanstalk - Multithreading within Tomcat thread

Question

I am running a Spring MVC application on Tomcat 8 on Elastic Beanstalk's worker tier. For those unfamiliar with Elastic Beanstalk, whenever an SQS event occurs, Amazon will automatically perform a POST request to my worker Spring MVC application. My application then processes the request and returns a 200 (unless something goes wrong obviously).

I would like to use concurrency while processing a single POST request. For example, let's say I need to perform 10 different expensive calculations. Instead of doing it serially, I'd like to use the ExecutorService to have 10 threads perform the work concurrently.

• Is this bad practice? If not, are there performance dangers in spinning up new threads in this way?
• How does the allocation of threads actually work (e.g. are they just stolen from Tomcat's thread pool or something else)?
• Should there be a shared thread pool accessible by all Tomcat threads? If so, how big should it be?
• Is it better to just break up the work into more SQS events and essentially distribute the subtasks to Tomcat threads, rather than doing it within a single Tomcat thread?

Answer 1

This is really multiple questions, but at the root is if it makes sense to use an ExecutorService inside of a queue worker implemented using Tomcat.

Is this bad practice? If not, are there performance dangers in spinning up new threads in this way?

This is perfectly fine, but you'll want to make sure you configure Tomcat to properly shutdown the executor service.

How does the allocation of threads actually work (e.g. are they just stolen from Tomcat's thread pool or something else)?

The ExecutorService will create its own pool of threads. The Tomcat threads cannot be used for your own purposes. There is nothing wrong with having this separate pool.

Should there be a shared thread pool accessible by all Tomcat threads? If so, how big should it be?

It makes sense to have a single pool that you would share across all of your Tomcat threads. The size is best determined by your specific use case, but the ExecutorService provides you with a number of options to create an efficient pool.

Is it better to just break up the work into more SQS events and essentially distribute the subtasks to Tomcat threads, rather than doing it within a single Tomcat thread?

This is really the important question. If you have separate independent tasks that are not related it probably makes sense to break them up into separate SQS messages. However, if you have separate tasks that are really part of a bigger task that can simply be executed in parallel keeping it as a single SQS message but using the ExecutorService to increase performance by processing parts in parallel is probably best.