> To start with, I'd take the naive approach and see whether it worked
> well enough for the job. I'd use thread.sleep(), and make sure I had
> enough worker threads (configured in server/conf.xml) to handle the
> number of outstanding requests you want to generate. That could be
> many thousands (I don't know your requirements), and each one
> potentially consumes a thread on the host operating system, so make
> sure you're running on a system that has enough memory and enough
> threads configured in the OS. Sorry I can't be specific on what
> "enough" is, but I've never done this myself!
>
> A second - and completely different - approach would be to throttle the
> bandwidth out of the server in some way, such that the responses were
> buffered for the required time. I'm not sure this is feasible at the
> link layer, as I presume you're using HTTP, so the TCP acks would have
> to get back in a timely fashion. If you're able to manage that
> somehow, though, connecting the Tomcat server via the networking
> equivalent of two tin cans and a piece of string - possibly a serial
> lead? - might provide the slowdown you're looking for.
A third solution: compute your result immediately, keep that in the
session as well as the time of the request, forward to a waiting view
that will wait client side and then ask the result on a specific URL,
then when asked for the result, check that 1) the result has been
computed, if this is not the case returns an error, 2) enough time has
passed, else re-forward to the waiting view. If all is correct, send the
result that lies in the session.
Benjamin Lerman
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
