We have a number of clients are sending GET requests to a servlet, which delivers to them large messages zipped up into files. The servlet has to go through quite a bit of work building these messages. If the clients have to wait too long they timeout and make their requests again.
We get into a situation where the request queue gets so long that all the requests at the front have timed out. We still have to do all the work to build the message, only to find out the client is gone once we start writing to the ServletOutputStream. Therefore the queue never gets shorter, and we don't successfully complete any requests. Ideally, we should detect that the client has timed out before we go to the trouble of building its message. Is there any way to detect that the connection is writable, short of actually writing to it?
Thanks for the reply! In this case the clients are hardware devices with minimal HTTP client functionality, and I don't know if they have implemented META REFRESH tags correctly or not. Say they have though, how does this strategy help me? I guess if the return of page B to the client fails, then we can find the running job thread and stop it. Is that the idea?
No, the idea is that you don't have to care whether the client times out. You just carry on producing the results; the clients will from time to time ask if you're finished yet; if you are then you send the result and if you aren't you tell the client you aren't. But note that the client, in this scenario, sends two different requests: the first asks for the server to do something, and the second asks if the server has it ready yet.
That avoids the scenario where a client sends a request; you start producing the result; the client times out and sends another request; you start producing a second result but you don't know you can just use the first result if it's ready. That scenario could overload your system by making it process more and more orphaned results.