jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: [servlet-spec users] execute(Runnable) Was: Race between error page dispatch and async servlet

From: Greg Wilkins <gregw_at_webtide.com>
Date: Wed, 26 Apr 2017 08:22:59 +0200

On 26 April 2017 at 00:35, Stuart Douglas <sdouglas_at_redhat.com> wrote:

>
> I agree that this would be very useful, although I don't like the name
> (but I can't think of a better one off the top of my head).
> With regards to the 'which is assumed to be a short lived, preferably
> non blocking, method.' part are you expecting that this will be run in
> an IO thread? Otherwise I don't really see any need for this
> restriction.
>


I think for the name, we should just use execute(Runnable) and then we are
giving a standard API to the containers executor. In fact we could
either just make AsyncContext extend Executor or perhaps just have a method
on AsyncContext:

/**
  * Get an Executor that serially executes submitted {_at_link Runnable}
tasks scoped
to
  * this request, either in a new thread, in a pooled thread, or in the
calling
  * thread, at the discretion of the Container.
  * Unlike AsyncContext#start(Runnable), the container guarantees that
  * the task will not be executed concurrently with any other thread
  * dispatched by the container for the associated request including others
  * executed via this Executor. Note that long running or blocking tasks may
  * cause execution of Servlet API callbacks to be delayed until after they
  * complete.
  * The container will propagate appropriate contextual information to the
  * thread executing the tasks, so that they have all the capabilities and
  * permissions of a container thread dispatched to the Servlet#service
method
  * for this request.
  * @return an Executor that will serially execute submitted {_at_link
Runnable}
  * tasks scoped to this request,
 */
Executor getExecutor();


regards



-- 
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com