4

Scenario:

  • Client makes ISAPI call with POST to IIS 7.5 server - the call will generate mission critical output to be distributed to numerous users. (using Delphi XE with Indy 9 HTTP client in this case);
  • ISAPI process takes a LONG TIME to complete (it's threaded on the client side);
  • Before the POST call returns, user aborts or client machine goes down, killing client side connection and leaving the ISAPI process chugging away on the IIS 7.5 server.

Questions:

  • What does IIS 7.5 do with that thread, which is still executing when the client/user aborts and kills the connection?
  • Will the server side thread complete processing even though the client has disconnected, or will IIS 7.5 kill that thread at some point, perhaps leaving a mess in the aborted process?
  • Is this time dependent - depending on how long it takes for the server-side process to complete?
  • Can this be controlled - can I instruct IIS to complete the process even though the client has aborted? If so, how?
gabr
  • 26,580
  • 9
  • 75
  • 141
Vector
  • 10,879
  • 12
  • 61
  • 101
  • IIS will notify active filters: [SF_NOTIFY_END_OF_NET_SESSION](http://msdn.microsoft.com/en-us/library/ms524855%28v=vs.90%29.aspx). I'm not sure but it seems to me that you need to write an ISAPI filter to handle these events (abort processing). – Ondrej Kelle May 20 '11 at 15:39
  • 2
    I know this doesn't really answer your question but putting this sort of processing within the ISAPI process is a bad architectural decision. If you have lots to do, I'd suggest asynchronously invoking another process to 'do the work'. – Steve Mayne May 20 '11 at 15:48
  • 1
    Only to clarify, my understanding is that by default the process would continue to completion, even though the client has disconnected. I could be completely wrong, though... – Ondrej Kelle May 20 '11 at 15:48
  • @Steve - 'asynchronously invoking another process' - I was considering something along those lines - might be the way to go. I also have a fairly simple workaround to negotiate this problem should it arise - but I'd like to know if there is a good, simple answer to this question. Tnx. – Vector May 20 '11 at 16:25
  • @TOndrej - "my understanding is that by default the process would continue to completion". I don't know what's the default - that's part of my question - but I tend to think otherwise - if I was writing a server I'd be checking dead connections and killing a process if the client 'hung up'. – Vector May 20 '11 at 16:30
  • 1
    @Mikey Definitely, but we're talking about an extensible server where the server has to pass control to an extension. In that case you would probably try to notify the extension about the fact that the client connection died (to allow it to perform some cleanup). From the documentation on MSDN, I've only found the above-mentioned `SF_NOTIFY_END_OF_NET_SESSION` notification, passed to an ISAPI filter. But I'm not sure about this. I hope I'm not misleading you with my comments. – Ondrej Kelle May 20 '11 at 17:11
  • @TOndrej - what you're saying makes sense, but I'm not anxious to start writing an ISAPI filter right now - I have a few solutions and answers before I resort to that. Tnx – Vector May 20 '11 at 18:34
  • @TOndrej - in the AppPool advanced config settings there are several options related to handling aborted, orphaned processes, etc. You can exercise some degree of control without a filter. Regardless, my testing showed that Darian's answer appears to be correct. – Vector May 20 '11 at 22:20

1 Answers1

3

IIS will continue to process until completion, or until the timeout for the App Pool is hit.

You should look at using Indy's TIdHTTPServer and then you'll control the server side which will allow you to setup your own rules on how to handle a long and possibly disconnected client session instead of becoming an expert in IIS AppPool management.

Darian Miller
  • 7,808
  • 3
  • 43
  • 62
  • 'until the timeout for the App Pool is hit': What timeout are you referring to? The only time-out available is the 'idle timeout' - which is applicable only if the worker process is indeed idle - not processing a request - that isn't applicable in my case. Do you mean the app pool recycling? I don't think recycling kicks in if a worker process is still doing work.Recycling is a form of built in, planned maintenance event - it should not shut down a running process. – Vector May 20 '11 at 21:01