Generally with 3.2.x it will throw there, but it may throw later due to
buffering.  And since the browser has closed the connection, no you can't
send/receive anything further.  Of course, there is nothing to prevent you
inclosing your code in a try {} finally {} block if workBean needs to do
cleanup.
----- Original Message -----
From: "Hu, Xuebing" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, November 01, 2001 2:39 PM
Subject: RE: How does Tomcat handle discarded-request


> Hi, Craig,
>
> Here is my skeleton jsp,
>
> <jsp:useBean id="workBean" class="..." ...>
> </jsp:useBean>
>
> <%
> Object param1=getParameter("Param1") ;
>         ...
>         Object paramn = getParameter("Paramn") ;
>
>         // let us say that doWork takes a few minutes to finish
>         // and I just can not wait at the browser side and I issues
another request to TOMCAT
>         Object result = workBean.doWork(param1, ..., paramn) ;
>
>         // Is IOException thrown out here?
>         out.println(result) ;
> %>
>
> As per your explaination, is IOException thrown out on out.println()???,
since it is JSP, so my workBean has no way to talk to something at the
browser side to get data.
>
> thanks,
> David
>
> > ----------
> > From: Craig R. McClanahan[SMTP:[EMAIL PROTECTED]]
> > Reply To: Tomcat Developers List
> > Sent: Thursday, November 01, 2001 5:08 PM
> > To: Tomcat Developers List
> > Cc: Hu, Xuebing
> > Subject: RE: How does Tomcat handle discarded-request
> >
> >
> >
> > On Thu, 1 Nov 2001, Hu, Xuebing wrote:
> >
> > > Date: Thu, 1 Nov 2001 17:03:29 -0500
> > > From: "Hu, Xuebing" <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > > To: Tomcat Developers List <[EMAIL PROTECTED]>
> > > Subject: RE: How does Tomcat handle discarded-request
> > >
> > > Thanks, Bill for the response. Any detail? I am currently using TOMCAT
3.2.3.
> > >
> >
> > In general, you cannot count on the server even knowing that the request
> > was cancelled.  The following scenarios are all possible:
> >
> > * The entire request was read before the cancel happened, so no
> >   notification is possible until the response is written back out
> >   and receives an IOException.  (This is by far the most common case.)
> >
> > * Tomcat was able to read the headers, but does not need to read
> >   the data.  In this case, it is the application (not Tomcat) that
> >   would receive an IOException when trying to process the input
> >   stream.  Therefore, it is up to your application to respond
> >   appropriately.
> >
> > * Tomcat was unable to read the headers (because the cancel happened
> >   very quickly).  It will typically log an exception and throw the
> >   request away.
> >
> > > David
> > >
> >
> > Craig
> >
> >
> > --
> > To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
> >
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>


*----*

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to