Re: requestdispatcher.include, flush bugs
Sorry for my imperfect english. I tried to do what you did and I have got
some unexpectable result. I created the page wait.jsp with a code exactly you
pointed in you e-mail and it really does not show anything in browser
although the page wait.jsp works perfectly itself. But when I put (below are
addresses which are valid for my configuration)
String waitPage = /jsp/dates/date.jsp;
instead of
String waitPage = /jsp/wait.jsp;
it works perfectly and shows the date.jsp for 60s then switches to pointed
uri (String uri = http://www.cnn.com;;)
Actually I use not so new version of Tomcat and Apache. I have jakarta
3.2.3-43, SuSE Linux 7.3 and apache-1.3.20-29
Hope it helps
On Wednesday 03 July 2002 21:35, you wrote:
could someone please point me to where i can log bugs for tomcat?
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.
tia, apu
i was wondering if anyone else has had problems with
RequestDispatcher.include() and flush() or is it just me? (see below)
i request someone to please deploy the code and see if it works at all,
or whether it's a setup/configuration thing from my end, though i don't
think so since all my other jsp/servlets are running fine. or whether i
am completely off the ball when it comes to implementing the concept.
-
i tried using the following code over http and it still didn't work.
any ideas would be appreciated.
tia, apu
-
i am using tomcat 4.0.3, apache 2.0.34 over ssl with the warp connector.
i have set the connector allowChunking to false.
the problem that i see is that after i use
getRequestDispatcher(page).include(req,resp) and flush the resp.out, the
page does not get flushed to the browser. essentially i am trying to
simulate a please wait page while my server does something that takes
a longish time.
am i missing something? i have explicitly flushed the buffer (using both
resp.flushBuffer() and out.flush()), set autoFlush=true, made
allowChunking=false anything else i can try or is this a
legitimate bug?
or does it have something to do with ssl? i haven't tried this without
ssl
here is sample code to illustrate
CODE START =
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class test extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException, ServletException {
// Set content type, et all
resp.setContentType(text/html);
// Include waitpage, flush response.
String waitPage = /wait.jsp;
getServletContext().getRequestDispatcher(waitPage).include(req,resp);
resp.getWriter().flush();
log(Flushed + waitPage,null);
// Sleep for a minute. The client browser should be viewing the
// wait page by now.
try {
Thread.currentThread().sleep(60*1000);
}
catch(InterruptedException ie) {
log(test,ie);
}
// Ok, we're ready to show the next page. Send a redirect.
PrintWriter out = resp.getWriter();
String uri = http://www.cnn.com;;
out.println(meta http-equiv=\Refresh\ content=\0; url= +
uri +\);
out.flush();
log(Sent refresh to + uri,null);
}
// Logging, for illustrative purposes only.
public void log(String msg, Throwable t) {
StringBuffer buf = new StringBuffer();
buf.append(this.getClass().getName());
buf.append( );
buf.append(msg);
ServletContext ctx = this.getServletConfig().getServletContext();
if(t != null)
ctx.log(buf.toString(),t);
else
ctx.log(buf.toString());
}
}
CODE END =
wait.jsp can be any jsp page, for example
%@page language=java autoFlush=true%
waiting.
i see the logs showing me that the wait page has been flushed. :
2002-06-25 12:52:07 jsp: init
2002-06-25 12:52:14 test Flushed wait page /wait.jsp
2002-06-25 12:52:47 test Sent refresh to http://www.cnn.com
but the browser never renders the wait page, instead it just waits for a
minute, and refreshes to www.cnn.com. i tried with different user agents
(netscape 6.2, mozilla 1.0 on linux and ie 6 on xp) to eliminate the
browser from the picture.
tia.
apu
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
requestdispatcher.include, flush bugs
could someone please point me to where i can log bugs for tomcat?
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.
tia, apu
i was wondering if anyone else has had problems with
RequestDispatcher.include() and flush() or is it just me? (see below)
i request someone to please deploy the code and see if it works at all,
or whether it's a setup/configuration thing from my end, though i don't
think so since all my other jsp/servlets are running fine. or whether i
am completely off the ball when it comes to implementing the concept.
-
i tried using the following code over http and it still didn't work.
any ideas would be appreciated.
tia, apu
-
i am using tomcat 4.0.3, apache 2.0.34 over ssl with the warp connector.
i have set the connector allowChunking to false.
the problem that i see is that after i use
getRequestDispatcher(page).include(req,resp) and flush the resp.out, the
page does not get flushed to the browser. essentially i am trying to
simulate a please wait page while my server does something that takes
a longish time.
am i missing something? i have explicitly flushed the buffer (using both
resp.flushBuffer() and out.flush()), set autoFlush=true, made
allowChunking=false anything else i can try or is this a
legitimate bug?
or does it have something to do with ssl? i haven't tried this without
ssl
here is sample code to illustrate
CODE START =
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class test extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException, ServletException {
// Set content type, et all
resp.setContentType(text/html);
// Include waitpage, flush response.
String waitPage = /wait.jsp;
getServletContext().getRequestDispatcher(waitPage).include(req,resp);
resp.getWriter().flush();
log(Flushed + waitPage,null);
// Sleep for a minute. The client browser should be viewing the
// wait page by now.
try {
Thread.currentThread().sleep(60*1000);
}
catch(InterruptedException ie) {
log(test,ie);
}
// Ok, we're ready to show the next page. Send a redirect.
PrintWriter out = resp.getWriter();
String uri = http://www.cnn.com;;
out.println(meta http-equiv=\Refresh\ content=\0; url= +
uri +\);
out.flush();
log(Sent refresh to + uri,null);
}
// Logging, for illustrative purposes only.
public void log(String msg, Throwable t) {
StringBuffer buf = new StringBuffer();
buf.append(this.getClass().getName());
buf.append( );
buf.append(msg);
ServletContext ctx = this.getServletConfig().getServletContext();
if(t != null)
ctx.log(buf.toString(),t);
else
ctx.log(buf.toString());
}
}
CODE END =
wait.jsp can be any jsp page, for example
%@page language=java autoFlush=true%
waiting.
i see the logs showing me that the wait page has been flushed. :
2002-06-25 12:52:07 jsp: init
2002-06-25 12:52:14 test Flushed wait page /wait.jsp
2002-06-25 12:52:47 test Sent refresh to http://www.cnn.com
but the browser never renders the wait page, instead it just waits for a
minute, and refreshes to www.cnn.com. i tried with different user agents
(netscape 6.2, mozilla 1.0 on linux and ie 6 on xp) to eliminate the
browser from the picture.
tia.
apu
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: requestdispatcher.include, flush bugs
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 pBeginning 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]
