I am debugging a web application from inside eclipse. I have written a servlet which has following piece of code inside the doPost method.
RequaestDispatcher's forward is forwarding to another simple JSP which renders HTML.
When debugger stops at breakpoint1 I do not see any output in the browser, but when debugger completes the execution of the breakpoint1 and stops at breakpoint 2, the response is flushed and I see the output in the browser.
My question is, if that is happening, that means, after the request was forwarded to the new request handler, it must spawn another thread to service that request, in other words, response is being commited in another thread.
I am confused because of this peculiar behaviour, can anybody comment on the exact behaviour ??
Thanks in advance
[ June 08, 2005: Message edited by: sachin pathak ]
I know that neither sendRedirect nor forward will stop the execution of the service method.
A good rule of thumb is to always follow a call to forward or sendRedirect with a "return" statement. Either that or set up your branching so that the return or sendRedirect staements are always the last call made for a given condition.
Originally posted by sachin pathak:
[QB]My question is, if that is happening, that means, after the request was forwarded to the new request handler, it must spawn another thread to service that request, in other words, response is being commited in another thread.
The request dispatcher may occur in a separate thread, and there are cases in which it must do so, but my impression was that in a single context it would either occur in the same thread or a new thread which the current thread would join (ie wait for).
There is a very important line you're omitting: how do you create your dispatcher? If you create a dispatcher in the same context using request.getDispatcher(...), you should be seeing the behaviour above.
However, if you're forwarding to a resource in a separate context or using getServletContext().getContext("something").getRequestDispatcher(...) (where 'something' is the current context name) you may run into some threading issues. I can't say if the behaviour is the same everywhere, but in some app servers (eg WebSphere), this causes you to access the requested resource through the thread pool i.e. you get another thread. If you use include rather than forward you can't control where the resource gets included!
So I guess my answer is "maybe"
ps Additionally, can the behaviour you're seeing just be due to the response buffer? That is it gets written when you say, but only gets flushed later.
[ June 08, 2005: Message edited by: David O'Meara ]