On Wed, 10 Sep 2003, Jing Zhou wrote: > Date: Wed, 10 Sep 2003 13:49:18 -0500 > From: Jing Zhou <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Cc: Craig R. McClanahan <[EMAIL PROTECTED]> > Subject: Re: What's the best strategy to handle this kind of thread > issues? > > > ----- Original Message ----- > From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]>; "Jing > Zhou" <[EMAIL PROTECTED]> > Sent: Wednesday, September 10, 2003 12:12 PM > Subject: Re: What's the best strategy to handle this kind of thread issues? > > > > On Wed, 10 Sep 2003, Jing Zhou wrote: > > > > > Date: Wed, 10 Sep 2003 02:16:49 -0500 > > > From: Jing Zhou <[EMAIL PROTECTED]> > > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>, > > > Jing Zhou <[EMAIL PROTECTED]> > > > To: Struts Users Mailing List <[EMAIL PROTECTED]> > > > Subject: What's the best strategy to handle this kind of thread issues? > > > > > > As we realize so far, a browser window may send > > > request A to a server. The server starts thread A > > > to handle it. Before the thread A returns, the same > > > window may send request B to the server, therefore > > > the server creates thread B to handle it. > > > > > > > Technically, the threads are usually there already in a pool, rather than > > being created, but that is not really relevant to your question. > > > > The only ways the same browser window can send more than one request > > (in the manner you describe) are: > > (a) User presses STOP and then manually triggers a second request. > > (b) A page includes one or more tags like <img> that fire > > off parallel requests for each image > > (c) Window includes multiple frames (the frames themselves > > are often loaded with parallel requests) just like (b) > > (d) JavaScript techniques similar in (b) that are used by the client > > to reassemble the output. > > > > So the answer to your question really depends on which use case we're > > talking about. In scenario (a), thread A will continue to run the > > original request, because the server has no way to know that the user > > pressed STOP. Because the client has closed the TCP connection, the > > servlet will generally encounter an I/O exception when writing out the > > response -- but if the response fits inside a buffer, it might not be seen > > until after the servlet returns. > > What we found in IE 6.0 sp1 is that end users do not have to press STOP > and then manually trigger a second request. They could just press buttons > in a web form and trigger different requests to the server. Is this a bug > in IE 6.0? (The scenario (a) looks correct in IE 5.0) >
I suppose that behavior is similar on lots of other browsers -- I just tried it on Mozilla 1.4 and it does the same thing; as far as the browser is concerned, it just stops paying attention to the original request and starts paying attention to the new one. > If we regard this scenario as (a+), then we know thread A could still be > executing in its valid mode (not cancelled or to-be-cancelled) after > thread B returns. > This is the crux of the issue -- there is no such thing as cancelling an HTTP request. There's nothing in the protocol analogous to typing a Ctrl+C into a command shell to interrupt the currently running program. The original request is going to keep running until it runs into an I/O error because the client closed the underlying TCP connection. And even that will often not happen until after the response has been completely written to the output buffer, and the container tries to flush it. All you can really do is detect that the situation happened, synchronize against multithread race conditions, and make sure that the second response sends back what you want (since the user isn't going to see the first response). Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
