2

I am using jetty, version 7.0.1 if that matters.

Sometimes I have some quite long running tasks on a server which I would like to cancel/stop if the client disconnects (in case of GET requests, not e.g. POST file uploads). It seems this is not the case, and that tasks continue to run to completion.

Perhaps I can use ServletRequestListener.requestDestoryed listener to get notification of such tasks but what is recommended approach for stoping the request thread? What about releasing resources like database connections, file handles or running tasks (executor service)?

What is the recommended approach in stopping such tasks as soon as possible?

user744959
  • 751
  • 1
  • 6
  • 13

1 Answers1

0

first I would recommend updating to the latest versions of jetty, we have fixed a ton since 7.0 series

second, your best bet to solve this problem is by design using either jetty-continuations to get async servlet support with servlet 2.5 spec (which is jetty7) or update to servlet 3.0 (jetty 8) and not rely on the get methods of the servlet api to block waiting for a response to send. Instead process the request and then spawn a thread or use an executor future to process the actions, then calling back to the request when you have a payload or success message to return. Reason being that while your in the servlet api blocking on the request process you are consuming resources and threads from your servlet thread pool...you'll be able to scale up much cleaner by using continuations or the async servlets of 3.0...

Also you'll be able to design a proper mechanism for managing these threads and things like timeouts and the proper notification mechanism for exceptional conditions, and it will be testable outside of a servlet container that way.

imo at least :)

jesse mcconnell
  • 7,102
  • 1
  • 22
  • 33
  • This doesn't really handle the case where the user aborts a "long" request. In fact, knowing when to abort an asynchronous request is trickier, because it requires more work to detect whether a client is gone for good. One of the chief questions is whether the container will fire the `requestDestroyed()` event before a servlet returns from its `service()` method if it detects the client has closed the underlying socket. I'm guessing it doesn't, as this could really screw up a servlet. – erickson Mar 17 '12 at 14:27
  • sure, but there is no contract in place with the servlet api for a client to indicate it is no longer interested like your looking for, maybe what you want is a ajax type model using continuations or async servlets where the client needs to keep a heartbeat every 30 seconds or something...checkout cometd for something like that, it is good stuff – jesse mcconnell Mar 17 '12 at 19:20
  • Yes, I think a Comet-based solution is the best bet. – erickson Mar 17 '12 at 21:37
  • I know the temporary resource usage can be mitigated in another ways, with continuations and executors. I have tried to boil down question to the real problem and that is that servlet model and jetty api does not seem to allow for detection of client disconnect and termination of current processing. Also don't know how browsers that use HTTP1.1 to issue multiple requests over the same socket interact with the servlet model? Alternatively, even I can't prevent resource wasteage, I could at least limit resource usage from such requests by a thread pool dedicated for their processing.. – user744959 Mar 18 '12 at 19:03