Our code isn't in a custom tag. Its mostly done by MVC..a request is sent to
a mapped servlet, which then calls an action class to handle that request.
>From there it populates the bean associated with the jsp page and form, does
some logic, then forwards to another JSP page to display any results, new
page, thank you, etc.
> -----Original Message-----
> From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 30, 2000 7:24 PM
> To: Orion-Interest
> Subject: RE: STOP button of browser causes connection leak..
>
>
> Orion does this, if you notice that when the user presses
> stop and your code
> is inside a custom tag, it throws an IOException : End of
> Pipe or something
> similar.
>
> Mike
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Duffey, Kevin
> Sent: Tuesday, October 31, 2000 12:00 PM
> To: Orion-Interest
> Subject: STOP button of browser causes connection leak..
>
>
> Hi all,
>
> Yet another problem I am posting for some help. It appears
> that when someone
> using our site submits a query that ends up being more than a
> few seconds,
> and they hit the STOP button (maybe because they made a
> mistake on the form
> for example), the server thread/request is still running.
> Since the STOP
> button has no way of being tracked (not even with
> JavaScript), is there some
> mechanism of Orion or the web server in general that is
> supposed to handle
> this? One of our engineers said that the web server should
> pick up on the
> connection being dead (back to the browser) so should abort
> the thread. The
> code we are running on Orion never had a problem with lost
> connections using
> our own home-brewed persistence layer, but it appears to have
> a problem with
> Orion. It is most likely our code, but one of our engineers
> thinks Orion
> doesn't properly handle a dead connection back to the browser
> (in the case
> of a STOP button or another link being clicked on).
>
> We use our own connection pool class, and generally we catch
> Throwable and
> always return a connection to the pool. Also, it appears as
> if the resource
> of that connection on the database gets locked, eventually causing a
> rebooting of the database server (we have to do it manually when the
> database runs out of resources).
>
> Thanks for any help on this matter.
>
>
