Concurrent programming inside a Java EE container

Question

I have a few Quartz scheduled jobs that are quite IO intensive and are easily breakables into multiple tasks.

The jobs are instantiated and scheduled inside the tomcat web container thanks to Spring.

Is it all right if I use the java.util.concurrent API within the Job class and inside the Java EE container ?

Can I share the logical processors with Tomcat by using and sizing a FixedThreadPool and giving away a few cores (like two in this example) ?

int numberOfCores = Runtime.getRuntime().availableProcessors();
final int poolSize = numberOfCores - 2 // Give away Two slots for TOMCAT
final ExecutorService executorPool = Executors.newFixedThreadPool(poolSize);

Answer 1

Yeah you can do that. But Before putting your job inside tomcat. Note the following.

Are you having a web app in tomcat? if yes ,Is your web app a highly active high load portal ?
If yes, your thread jobs will take away valuable processing from the tomcat server

Is the Job done by thread jobs tightly coupled or require tomcat ?
If your jobs are really in depended . you should better create a separate batch server and use it. You can look to spring-batch for an implementation.

Answer 2

Maybe, carefully.

Be aware that no thread (other than the original one - let's call that the web-app thread) will be able to reliably interact with the container. In general, using threads in a Java EE runtime is discouraged. It's not unheard of though.

Tomcat Options:

1. Java EE has a WorkManager API . There is at least one implementation of it for tomcat . I can't speak to how well it works. This article talks more about it .

2. Start your own threads. A model for how to manage things might be the Swing Event Dispatch Loop with SwingUtilities.invokeLater(Runnable) ; in your case have worker threads submit work-to-be-done-in-the-container back to the container-safe web-app thread. That thread would be running aa handle-work loop while waiting for worker-threads to complete.

3. Launch worker requests back into the tomcat server: your web-app now acting as a client (web service?). Such a model would scale nicely to off-load the work, as AkhilDev suggested, to other servers.