I've recently been thinking about application uses of servlet-async and
Websocket for long-running operations, or really for any interactions
where you want to allow the request-processing thread to go back into
the pool, but the application is still doing useful things and therefore
needs its own thread.

I'm thinking of something like SwingUtilities.invokeLater, though that
does something very specific that is AWT-related, of course.

I don't believe there is a (JavaEE/JakartaEE) standard for this, so I'm
interested in what others think might be a good idea from a Tomcat

It's fairly easy to do something like this in one's own web application,
maybe using a ServletContextListener:

public class ExecutorProvider
  implements ServletContextListener
  public static final EXECUTOR_SERVICE_KEY = "executor-service";

  private ExecutorService _svc;

  public void contextInitialized(ServletContext ctx) {
    _svc = Executors.newFixedThreadPool(10); // ?

    ctx.setAttribute(EXECUTOR_SERVICE_KEY, _svc);

  public void contextDestroyed(ServletContext ctx) {

Then in a servlet, etc. you could:

Runnable() {
    public void run() {
        // your code goes here

I'm wondering if there is scope here for Tomcat to provide this kind of
service for applications that want to opt-into one. Maybe the above is
so trivial as to not be worth it at all. But maybe it would be a nice
service to provide to web applications, or maybe across multiple web
applications in some kind of group. Or it might survive context restarts
for some reason.

Having this provided by Tomcat would allow admins to maybe override the
sizes of the thread pools and other details that the application then
wouldn't need to worry about.

It might even tie-into Tomcat's utility-executor if that makes any sense
0-- though we'd have to make sure it executes in the right ClassLoader
and/or security context.

Any thoughts on this? Or is it really such a trivial thing as to not
really be useful to anyone. Maybe simply providing a
ServletContextListener class like the one above (with obvious robustness
improvements) that anyone could configure for their own application
would be sufficient/useful to users.


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to