tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rossen Stoyanchev <rstoyanc...@vmware.com>
Subject Re: IOException from the response during an async request
Date Sun, 05 May 2013 16:29:02 GMT

----- Original Message -----
> From: "Mark Thomas" <markt@apache.org>
> To: "Tomcat Users List" <users@tomcat.apache.org>
> Sent: Sunday, May 5, 2013 11:35:54 AM
> Subject: Re: IOException from the response during an async request
> 
> > From what I can see to complete the async request in this (or any
> > async scenario) one has to call asyncContext.dispatch(), wait for
> > the dispatch, and then call asyncContext.complete() in the dispatched
> > thread, or let the dispatched thread complete. And this is true
> > even if the IOException occurred in the brief period after startAsync
> > but before the initial container thread has exited.
> 
> In the non-error case, you can call complete() or dispatch().
> 
> The non-error case is (currently) different.
> 
> If you call complete() you'll end up with an IllegalStateException
> when the error handler kicks in. You have to use dispatch(). The error
> handle kicks in as soon as the dispatch() tries to write to the response.

I have no need to write to the response. I know it blew up and am trying to find a way to
complete the request.

Javadoc for complete() says it is legal to call it without making further qualifications.
Based on that alone I would expect complete() to just work.

I presume the error handler kicks as a result of the IOException from the response? And it
probably notifies listeners asynchronously so by the time it gets around to doing that, I've
already caught the exception and called complete(). If this is true there seems to be an inherent
race condition. I.e. even if dispatch, couldn't the dispatch complete sooner? Given that onError
handlers aren't going to do I/O would, would it be feasible to call them synchronously? Or
at least have some synchronization that holds up completion if error handlers have not been
notified.

> > This is based on the Javadoc of asyncContext.complete() by the way:
> > 
> > * <p>It is legal to call this method any time after a call to *
> > {@link ServletRequest#startAsync()} or * {@link
> > ServletRequest#startAsync(ServletRequest, ServletResponse)}, * and
> > before a call to one of the <tt>dispatch</tt> methods * of this
> > class.
> > 
> > It seems rather convoluted for dealing with exceptions from the
> > response especially in cases where the client has gone away, so I
> > just wanted to confirm it's the correct way and the only way.
> 
> Some guidance from the EG would be good here. It does seem more
> natural that a call to complete() should be sufficient in this case. However,
> that appears to preclude the error handlers from firing since the
> description of error handlers describes the request completing after
> the handler is fired.
> 
> Maybe:
> complete() - no error handler
> dispatch() - error handler

>From an application perspective, it would be best to aim for consistent behavior for complete().
The dispatch doesn't give any benefit for the application for the added complexity and effort.

> One for the Servlet EG I think.

It would be useful to clarify indeed. Are you posting the question or should I?

Thanks,
Rossen

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


Mime
View raw message