Hi Chris, On Fri, Sep 18, 2020 at 7:10 PM Christopher Schultz < ch...@christopherschultz.net> wrote:
> All, > > 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 > standpoint. > I haven't used Java EE since version 5 but I do remember it having such utilities: https://docs.oracle.com/javaee/7/tutorial/concurrency-utilities.htm > > > 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) { > ctx.removeAttribute(EXECUTOR_SERVICE_KEY); > _svc.shutdown(); > } > } > > Then in a servlet, etc. you could: > > > ((ExecutorService)ctx.getAttribute(ExecutorProvider.EXECUTOR_SERVICE_KEY)).submit(new > 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 > I agree - it is trivial. But also: does it work for everyone's use case ? Some will need a fixed pool for CPU bound tasks, others will need a cached pool for IO bound tasks, and others may need a scheduled pool ... And then you'll need to provide a way to name the threads ... Of course you can introduce pools of all types but is it easier to define them in XML (server.xml, context.xml) or in Java code (as you did above) ? My 2c Martin > 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. > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
