Hi Chris, Isn't it EE concurrency utilities? executors are injectable and designed to be used by the app and managed by the container. you can find an impl (for sample purposes) in https://github.com/apache/tomee/tree/master/container/openejb-core/src/main/java/org/apache/openejb/threads, then it is just a matter of defining it as resources in tomcat and do a lookup in any init method to get it I think, we can. Code is trivially extractable from tomee if it is what you have in mind and Apache Geronimo can be a "shared" home for such lib by "design".
Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 18 sept. 2020 à 18:10, Christopher Schultz < ch...@christopherschultz.net> a écrit : > 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. > > > 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 > 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 > >
