Le mar. 22 sept. 2020 à 08:54, Martin Grigorov <mgrigo...@apache.org> a écrit :
> 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) ? > Hmm, a few points: 1. You are right, I think the only thing the mentionned impl does not handle is the cached executor service but it is trivial to add (but has the pitfall to make the app less deterministic), everything else is there. 2. Java code definition is trivial by nature (since it is java code) and XML support is there too (tomee flavor: https://tomee.apache.org/admin/configuration/resources.html#_managedexecutorservice, tomcat one too since tomcat has a XML factory support - setters, factory method etc, same as for datasources). Indeed it does not bring a specific XML support (and I have to admit it is a very good thing) but it is coded to be "XML factory friendly" so we are all good there, in particular in Tomcat. 3. Assuming you don't go with the standard and share an impl @asf, wouldn't you just redo exactly the same thing? Sounds like it is the proposed path anyway, no? So probably better to make a single community rather than split it since this part is pretty simple and stable IMHO. Indeed, just my opinion but from my experience it is always trivial to launch a new project, it is way harder to make it last in time in terms of community, here spec helps and we can easily make it usable outside a full EE container (ie just servlet container scope). > > 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 > > > > >
