tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Guillemot <mguille...@yahoo.fr>
Subject Re: Proposal: Some todo's at AsyncContext detected...
Date Wed, 30 Jun 2010 15:01:32 GMT
Hi,

What you write means that the freshly release Tomcat 7 doesn't fully 
implement Servlet API 3.0, isn't it?

Interesting to see that nobody reacts :-(

Cheers,
Marc.

Peter Roßbach wrote:
> Hi!
> 
> I detected some Todo's at AsyncContext
> 
> -   AsyncContext.createListener
>     We don't make a resource injection or make it configurable!
> 
>     Servlet 3.0 API comment:
>     "This method supports resource injection if the given clazz 
> represents a Managed Bean. See the Java EE platform and JSR 299 
> specifications for additional details about Managed Beans and resource 
> injection."
> 
> -   I miss the is[Started,Completed] methods at AsyncContext interface
>     The only way to detect a completed state at AsyncContext inside an 
> AsyncListener is:
>         if (ac.getResponse() != null)
>     AsyncListener got an event, with empty state... -- Very strange!
> 
>     Can't we clear all AsyncListener after send complete and before we 
> refresh the AsyncContext state?
>     How can a user handle a completed situation?
>         see o.a.c.core.TestAsyncListener
> 
> -   AsyncContext.start() dosen't really start a thread!
>         We create wrapper of a Runnable, but we don't start a thread...
>         Error handling seam a little bit strange.
>             We only throw a RuntimeException(ex) and log an error!
> 
>         Servlet API comment:
>         "Causes the container to dispatch a thread, possibly from a 
> managed thread pool, to run the specified Runnable. The container may 
> propagate appropriate contextual information to the Runnable."
> 
>         How can we implement that?
>             Start everytime a new thread without pooling?
>             Use the connector executor pool from request?
>                 Then we must extend the ProtocolHandler interface with 
> getExecutor() signature.
>             Use a separate Executor pool per Engine/Host or Context
>         How do we have to implemented the error handling?
> 
> - JioEndpoint has a timeout detection thread, but we don't start it!
>     I easy fix it with revision 958362,
>     but the polling strategy is slow and ineffectiv.
>     I didn't make a test at NIO/APR-HTTP or AJP-Connectors.
> 
> - After the timeout event is emitted, the completed method is 
> automatically called!
>        Servlet API 3.0 Spec says:
> ====
> ■In the event that an asynchronous operation times out, the container 
> must run
> through the following steps:
> ■ Invoke the AsyncListener.onTimeout method on all the AsyncListener
> instances registered with the ServletRequest on which the asynchronous
> operation was initiated.
> ■ If none of the listeners called AsyncContext.complete() or any of the
> AsyncContext.dispatch methods, perform an error dispatch with a status
> code equal to HttpServletResponse.SC_INTERNAL_SERVER_ERROR.
> ■ If no matching error page was found, or the error page did not call
> AsyncContext.complete() or any of the AsyncContext.dispatch
> methods, the container MUST call AsyncContext.complete().
> ===
>         I miss the implementation that we call the error page!
> 
> - Currently a AsyncListener can't reinit a async cycle!
>     see o.a.c.connector.Request.startAsync
>     ... L1555ff
>             if (asyncContext==null) {
>             asyncContext = new AsyncContextImpl(this);
>         } else if (asyncContext.isStarted()) {
>             throw new IllegalStateException("Already started.");
>         }
>     ...
> 
> What does this spec definition really mean?
> === Ch 2 Page 18
> ■public void onStartAsync(AsyncEvent event) - Is used to notify the
> listener that a new asynchronous cycle is being initiated via a call to 
> one of the
> ServletRequest.startAsync methods. The AsyncContext corresponding
> to the asynchronous operation that is being reinitialized may be 
> obtained by
> calling AsyncEvent.getAsyncContext on the given event.
> ====
> 
> -   AsyncListener doesn't receive a onStartAsync event.
>     We don't implement it.
> 
>     At AsyncListenerWrapper fireOnStartAsync is missing
>     As AsyncContext.startAsync method doesn't emit an event
> 
> - ContextClassLoader at AsyncContext.dispatch is not set!
>     I can't see that we correcly set the application ContextClassLoader 
> before
>     we dispatch the Request. What must we do at a CrossContext dispatch?
> 
> - After first complete async cycle, an AsyncListner receive onStartAsync 
> as code start next async cycle?
> 
> Why doesn't the Servlet 3.0 TCK check basic AsyncContext functionalities?
> It seams that we better start a open test suite implementation at the 
> new Servlet 3.0 API.
> 
> Regards,
> Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message