The questions have been posted on the Servlet spec user list: https://java.net/projects/servlet-spec/lists/users/archive/2013-05/message/5
On Sun, May 5, 2013 at 1:34 PM, Mark Thomas <ma...@apache.org> wrote: > On 05/05/2013 17:29, Rossen Stoyanchev wrote: > > > > ----- Original Message ----- > >> From: "Mark Thomas" <ma...@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. > > In the non-error case it does. > > The error handling for errors on non-container threads is not well > specified. > > > I presume the error handler kicks as a result of the IOException from > > the response? > > No. The IOException sets a flag that an error has occurred. Once the > control returns to the container the error handling kicks in as soon as > that flag is checked. > > > And it probably notifies listeners asynchronously > > No. Listeners are notified synchronously. > > > so by > > the time it gets around to doing that, I've already caught the > > exception and called complete(). > > No. Calling complete() hands control back to the container. > > > If this is true there seems to be an > > inherent race condition. > > The analysis is way off. There is no race condition here. > > > I.e. even if dispatch, couldn't the dispatch complete sooner? > > Potentially the error flag could be checked sooner for both complete() > and dispatch(). However, I'm not sure at this point what affect that > would have on the current error handling. > > > Given that onError handlers aren't going to do I/O > > would, would it be feasible to call them synchronously? > > They are called synchronously. This is a single threaded ordering > problem not a multi-threading timing problem. > > > Or at least > > have some synchronization that holds up completion if error handlers > > have not been notified. > > That solution is trying to solve a problem that doesn't exist. > > >> 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? > > Go for it. The questions as I see them are: > > 1. What error handling, if any, is triggered if an Exception occurs > during asynchronous processing (e.g. an IOException because the client > dropped the connection) > a) on a container thread > b) on a non-container thread > > After our I'm leaning towards none for both. > > 2. After any such exception what mechanisms are available for the > application to complete async processing? > > I'm leaning towards: > complete() and dispatch() > > With dispatch likely to be a poor choice if there has been an IO error > as the chances of being able to return anything to the user are slim > (but if/when that does fail AsyncListener.onError() will be triggered as > per the current spec). > > Essentially Tomcat does all of this apart from allowing complete() > (because the error flag get checked). > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
