Re: Application-accesible Executors

[Romain Manni-Bucau]

Le mar. 22 sept. 2020 à 08:54, Martin Grigorov  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
> >
> >
>

Re: Application-accesible Executors

[Martin Grigorov]

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

Re: Application-accesible Executors

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | 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
>
>

Application-accesible Executors

[Christopher Schultz]

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