balakarthik.baska...@wipro.com wrote:
Yes you are right.I think I didn't mention it clearly.I am having this while
loop for writing a huge chunk of data followed by a thread that sleeps for some
time and that is where I am expecting my reply_timeout to be timed out and the
data written till the sleep of the thread is seen in the browser and the log
file.
Ok, now I do understand better, I think.
There is a request.
The Tomcat app starts answering (a long chunk of data), then crashes.
This is simulated by your test script, which sends a long chunk of data,
then sleeps (to simulate a crash).
Eventually, some timeout occurs, which (may) cause another element to
consider this Tomcat unresponsive, and switch the request to another one.
This other one then restarts the request from the beginning.
The final result being that the requesting browser first received an
incomplete chunk of data from the first webapp, and now starts receiving
the same data (again) from another webapp.
Again intuitively, I don't know how any server-side scheme is going to
solve that.
When the first webapp starts answering, that Tomcat has to start sending
the answer back to the client. If it then crashes, it is too late to
"call it back"; the data is already on the wire to the client.
It would be in my view the client's responsibility to ensure that it
discards any incomplete data received.
But I don't know of any browser for instance, which does that.
They all start to try to display the data as soon as they have the
beginning of it.
I think that if you really need this, then you would have to insert some
other "item" between Tomcat and the client, which acts as a proxy, and
only starts sending the response to the client when it is sure that it
has received and buffered a complete response from the server.
But then, this "item" becomes the weak link. It could also crash..
Or else you need an applet at the client side, which does the same thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
