Spring ThreadPoolTaskExecutor in Tomcat webapp - bad practice?

Question

Recently, in my project, I had to perform some tasks asynchronously. Since we are running webapp with Spring inside Tomcat, the ThreadPoolTaskExecutor provided by Spring was the solution.

However, the architect raised some objections, stating that it was horrible / forbidden / absolute evil to spawn a thread / have a thread pool in webapp.

Searching the web and in StackOverflow a bit, I realized that yes, it is bad practice to have your own thread pool inside the Java EE container. The rationale was that if you have your own thread pool, the container does not know about it and cannot properly manage resources. This is especially important when you need to do some hot deployments of your web client.

Now, our use case is the Spring webapp launched inside Tomcat. First, is it possible to consider a Spring container as a lightweight Java EE container? In this case, it’s Spring, which manages the threadpool lifecycle itself and not the application itself, does it?

Second, is the hot deployment argument applicable to this configuration?

And yes, I know that you can declare a work pool directly in Tomcat and inject it through JNDI in Spring. But this is a bit of a hassle compared to the direct ThreadPoolTaskExecutor provided by Spring

So, my last question: is the objection of architects relevant in my case?

Thank you for your suggestions and thoughts on this topic.

Answer 1

There are different levels of evil, and not all of them are actually considered evil in every situation.

Creating threads on demand instead of using a pool is usually considered evil, but this is not true for Java EE and runs for almost any type of server application.

In Java EE, creating your own thread in an EJB container is not particularly allowed. This relates, in particular, to the fact that Java EE containers can discreetly store contextual data in a local thread store, which is lost if the code runs in its own thread.

A web container, however, does not have such restrictions, and, according to the specification, it is more or less legal to have thread pools. This, for example, is the reason why people started Quartz from the web module in the EAR, even if they only used EJB modules or why the code from the web module could register callback listeners in unmanaged JMS queues, but EJBs could not do this.

However, in practice, creating threads (through pools) almost always works, if you remember that if you use, for example, EJB, you need to get instances from JNDI in the code running in these threads and not pass EJB references to these unmanaged threads. Of course, you need to take care to disable your pool, but almost every listener when loading into Java EE has a corresponding disabled listener where you can do this.

Java EE has some official ways that reduce the need to create your own pools:

• @Asynchronous annotation
• Sending a JMS message and processing it in MDB
• Using AsyncContext#start() (which is limited for general use, see What is the purpose of AsyncContext.start (...) in Servlet 3.0? )
• Using the work manager API (in fact, it is intended for use by vendors of JCA connectors and is therefore not optimized for end users, see http://www.adam-bien.com/roller/abien/entry/easy_threading_and_concurrency_in and http://connectorz.adam-bien.com )

However, some algorithms require separate thread pools to prevent blocking. Since none of the Java EE solutions gives you an absolute guarantee that the work is performed by different thread pools, sometimes there simply is no other plausible way than to create your own pool.

So, in the latter situation, it is actually more evil to open your code for locks than to create your own thread pool.

Answer 2

Imho, which has TaskExecutors self-control inside a Java EE application, is not a bad practice if it is properly isolated. Separating asynchronous tasks into an isolated instance represents a new level of complexity, a new dependency, and reduces performance.

The architects argument, which is not managed, of course, is null, since the container does not know / own many instances (for example, static links), and you can configure the executor itself in the @Configuration class or inside spring config, creating at least itself container-managed performer.

In addition, spring itself provides several methods for executing scheduled methods, for example, using the @Scheduled annotation (http://static.springsource.org/spring/docs/3.0.x/reference/scheduling. HTML)

The hot deployment dependency depends on how your work queue is configured and how your asynchronous task is handled.