[prev in list] [next in list] [prev in thread] [next in thread] 

List:       struts-user
Subject:    RE: What's the best strategy to handle this kind of thread issues?
From:       "Andrew Hill" <andrew.david.hill () gridnode ! com>
Date:       2000-03-04 3:34:58
[Download RAW message or body]

<snip>
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)
</snip>

Ive seen this too. Had to debug an issue recently  that only affected IE6
users - turned out to be due to a mistake in my page - I had a submit button
(instead of a link as Id been using on other pages) that triggered an
onclick event that performed some javascript which ended with a
form.submit() call.

In IE5 (which is what Id been developing with) the code caused no problems,
but in IE6 clicking the submit button would cause a natural submit to occur
AND my javascripts submit() would also work, resulting in a second request
swiftly following the first (and generally resulting in a error). Sometimes
the first request would get processed second and the page worked, other
times the second one would get processed second and so the error was
displayed. We had to tell the users to 'keey trying' until I had a chance to
fix the problem!

Can't rememeber what the mozilla behaviour was now. (None of the users is
using it , though of course I make sure our app is compatible). hehe if it
also happens in mozilla then its ie5 thats buggy otherwise its 6 ;->

-----Original Message-----
From: Jing Zhou [mailto:jing@netspread.com]
Sent: Thursday, 11 September 2003 02:49
To: Struts Users Mailing List
Cc: Craig R. McClanahan
Subject: Re: What's the best strategy to handle this kind of thread
issues?



----- Original Message -----
From: "Craig R. McClanahan" <craigmcc@apache.org>
To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>; "Jing
Zhou" <jing@netspread.com>
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 <jing@netspread.com>
> > Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>,
> >      Jing Zhou <jing@netspread.com>
> > To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> > 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)

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.

>
> In scenarios (b) - (d) the requests run in parallel and the client
> assembles the resulting page.
>
>
> > Assuming thread B finishes earlier than thread A, we
> > could have the following possibilities:
> >
> > 1) The server waits thread A to finish and send response A
> >     and then send response B. (I do not believe this is the
> >     Tomcat implementation, correct?)
> >
> > 2) The server sends response B back to the browser
> >     window and the browser window displays it and ignores
> >     response A after it.
> >
> >  3) The browser displays response B and then displays
> >     response A.
> >
> > What I can see is that thread B is the trouble maker. But it
> > is possible when end users click more than one buttons.
>
> This is my scenario (a) use case, and behaves as I described above.
>
> > In Swing, such problems are resolved by Single Thread
> > Model. Should we follow Single Thread Model at
> > servers? Are there any other practical solutions to it out
> > there?
>
> The key problem in dealing with scenario (a) is detecting that it has
> even happened.  The most important case is when you're doing a POST that
> updates the database -- for example, you don't want an order to be
> submitted twice simply because the user pressed SUBMIT, hit the back
> arrow, and pressed SUBMIT again.  The "transaction token" facility
> provided by Struts can be used to detect the second submit.
>

When dealing scenario (a+), thread B returns an error message from
our custom token facility. The browser window displays it (Fine). But the
window does not display any more responses from thread A. Is this
the supposed behaviors of browser windows or another bug in IE?
It is terrible anyway.

> Note that there is an API called "SingleThreadModel" in servlets, but it
> has nothing to do with this kind of problem, and should be avoided anyway
> (it's being deprecated in Servlet 2.4) because it doesn't really solve all
> of the problems that it tries to solve.
>

The Servlet API about "SingleThreadModel" is irrelevant to our problems.
I am thinking if we could block thread B or cancel it using a Filter at
server sides
with a concept similar to Swing. Such ideas could be very wrong as
I explained in my message, due to exception handlings.

> >
> >
> > Jing
> > Netspread Carrier
> > http://www.netspread.com
> >
> >
> >
>
> Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]