aspose file tools*
The moose likes Sockets and Internet Protocols and the fly likes Testing for closed connection Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Sockets and Internet Protocols
Bookmark "Testing for closed connection" Watch "Testing for closed connection" New topic
Author

Testing for closed connection

Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2854
    
  11

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?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18662
    
    8

Seems to me you would be better off assuming that you can't produce the data in time. Then you would implement one of the semi-standard processes that go like this:

1. Page A requests a job; servlet A starts the job running in a separate thread and returns page B.

2. Page B says "Processing..." and has a META REFRESH tag that requests servlet B.

3. Servlet B sees if the job is complete; if it is, it returns the data. If not, it returns page B again.
Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2854
    
  11

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?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18662
    
    8

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.
 
 
subject: Testing for closed connection