2009/9/29 aaime74 <andrea.a...@gmail.com> > But in the meatime I would really appreciate if anybody could > answer my first question: how does one detect the client connection > has been dropped? Is there any way? Does anybody know?
First off, I assume you're serving these straight out of Tomcat to the client - there's no proxying or Apache httpd to complicate things. I think you already said that, but this thread's gone down so many twists that I've mislaid the information - my apologies. I don't believe that Tomcat provides any such detection mechanism "out of the box". It certainly doesn't provide any termination mechanism - terminating a CGI script is easy as you know the code's held inside a nice neat bundle of a process, but aborting a Thread in Tomcat could leave a horrible legacy behind as it's all in the same address space. However, I think detection would be relatively simple to add. First off, let's assume that the OS's stack and Java's socket implementation work well enough together that isClosed() and isOutputConnected() on the socket actually give you meaningful information. If that's the case, "all" you need to do is to be able to get direct hold of the Socket that's writing the bytes and call appropriate methods on that. I would assume there's no way of doing this through the API, as it completely breaks layering. At this point, I'd be cracking open the Tomcat source and hacking in The Simplest Change That Could Possibly Work, just to see whether it does! In my case, that would involve some disgusting non-production hackery like putting a reference to the Socket onto thread-local storage once you know which thread will be handling the request, and making absolutely sure I took it out again as the request returned. Absolutely not what you want to do in a production system, but useful for a proof of concept. It's then possible to ask the Socket about its state directly in various places in the rendering pipeline, and abort the render if it's no longer required. I'd then do further work to refactor this so that there's some more appropriate (but Tomcat-specific) API, rather than the hackery described above. This does mean that you'd end up with a custom Tomcat, and hence your own code to maintain through upgrades. I suspect it's sufficiently isolated that such maintenance wouldn't be too big a problem, but you'd definitely be compiling from source. That's not a huge undertaking - I've done it on a couple of past projects. Happy to chat further if this looks like a useful approach. If you don't want to code it yourself, I suspect there are several people on-list with the skills and experience to construct such an addition. - Peter
