Today I was looking at some web app code that used Executors.newSingleThreadScheduledExecutor() on a per request basis to poll a REST API for a final status (think COMPLETE, FAILED, etc.). Knowing that a servlet container is already a highly concurrent environment, it worried me each request thread was creating another thread.
I have looked at creating a fixed sized thread pool but I'm not certain if it has to be managed in a servlet container specific way. I'm unsure how to decide on an optimal size. I'm also not completely confident that this is the right course of action.
I'd like to confirm that this indeed is dangerous with of an explanation of why and understand what a superior solution might look like.
The servlet AsyncContext.start(Runnable) is the preferred way if you want to interact with the Servlet API and contexts from within your Runnable (this will run within the Servlet Container's Thread Pool and allow the container to manage the various contexts around your thread, like classloaders, security, cdi, sessions, etc).
The ONLY downside with the AsyncContext approach is that you are consuming Servlet Container threads to do your processing. If you also use Servlet Async I/O, then you've offset this negative in a grand way, and you'll actually have a noticeable improvement in your ability to scale.
If you have no requirement to interact with the Servlet API from your Runnable, then go with simple threads executed from a Thread Pool you have obtained from the Java Executors.