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
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

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

Reply via email to