On Wed, 3 Jul 2002, Apu Shah wrote:
> Date: Wed, 3 Jul 2002 15:35:22 -0400
> From: Apu Shah <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: requestdispatcher.include, flush bugs
>
>
> could someone please point me to where i can log bugs for tomcat?
>
http://nagoya.apache.org/bugzilla/
> i have tried the code below on different configurations with no avail, i
> still see the problem, which makes me feel that it is a legitimate bug.
>
> i am assuming that it would not be appropriate to post on tomcat-dev (?)
> please advise.
>
> once more i request anyone of you to please verify that this is a
> legitimate bug (if even one other person sees it, i will be convinced
> that it is a legitimate bug), i have tried it without succes.
>
> any help would be greatly appreciated.
>
I don't think flushing the writer at the servlet level (you should really
be calling response.flushBuffer() for this anyway) is guaranteed to get
the data to the client -- it could easily be buffered in the SSL layer,
or in proxies in between. And even if it does, the client itself might be
buffering things up until the end of a paragraph or something. For
example, if you send "<p>Beginning of a paragraph" without the closing
</p>, it is quite likely to be sitting inside your browser because the
paragraph cannot be formatted yet.
A better approach to "please wait" pages is to do something like this:
* Fire off the lengthy process in a separate thread.
* The separate thread should indicate that the results are ready
by adding them to the user's session and then exiting the thread
(You'll need to pass a reference to the session to this logic
at thread startup time).
* Immediately return a complete "please wait" page (including
returning from the doGet() method) that includes a meta refresh
tag to periodically refresh itself, waiting for the results.
* Each time the meta refresh tag fires, the responding servlet will
see if the results have been finished yet (i.e. the separate thread
put something in the session).
- If the results are not ready yet, regenerate the "please wait"
page again
- If the results are ready, display them in the usual way.
Fancier approaches to this idea give the user the option to "cancel" the
long-running request by clicking a link or button on the "Please wait"
page instead of letting it refresh itself. You'll have to program the
logic that's running in your separate thread to be interruptible (say, by
checking for a different attribute in the session), but the basic design
pattern is pretty powerful.
> tia, apu
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
