Are there any guarantees about when IIS might recycle while processing a 1-way WCF operation?

Question

Background

This question is in two parts.

I have a one-way WCF operation hosted in IIS 6. The following is my understanding of how this works:

_1. IIS receives a request.

_2. IIS sends an HTTP 202 response (thanks, I'll process this later).

_3. IIS calls my one-way WCF operation.

Now control passes to my WCF operation which does the following:

_4. Persist the request info to a transactional, durable store.

_5. Start processing the request in the OLTP database.

_6. If there's an error, repeat from step 5, or take some remedial action, then cleanup the data persisted in step 4.

Question 1

Is my understanding of when IIS sends the HTTP 202 response correct?

Question 2

If IIS recycles between step 2 and step 4, I could lose the request information before I've had a change to persist it but after the client thinks I've accepted the message. Are there any guarantees provided by IIS about when it will or won't recycle when there are requests pending?

---

PS: Please excuse the dodgy formatting. For some reason markdown was totally screwing up my numbered list items.

Answer 1

In my opinion, there are a couple of things I would suggest:

The only way that I know of to manage process recycling in IIS is to look at the Application Pool your web site is using. If you open IIS Manager -> Application Pools -> select your Pool then right-click properties, on the Recycling tab there are options in there that might help you. I guess that doesn't guarantee that you won't lose requests in a recycle, but setting a longer time reducing the probability of such a case.

However, it sounds like the kind of system you're looking to build is an ideal candidate for MSMQ, which can provide asynchronous service requests that are queued properly with very little overhead or manual plumbing. That would allow you to avoid the whole process recycling problem entirely. I'm not sure if that's an option for your scenario, but it might be something to look into.

Answer 2

I'm not sure your assumption is correct.

Even for one-way interaction, WCF can get very invovled before the 202 is returned; if you use authentication, for example, it all has to happen before the method is called and before 202 is returned, so that if there are any problems they can be reported.

If you use wsHttpBinding, for example, out of the box, you will see 2-3 message exchanges resulting in 200 before the actual method call. this is to exchange security information and establish security context.

Admittedly, if you configured your service to have no security, this will not happen and it will return 202 immediately, but this suggests that it has to know whether it can do that from the WCF stack.

All that aside - I'm not sure what you are trying to achieve - which IIS recycling do you refer to? I'm not at all an expert on IIS, but I doubt it would recycle the host while something is actively executing; if you are refering to anyone manually restrting the application pool (or IIS, or the machine for that matter) I doubt there's much you can do.

If you have to know for sure that a message is not lost the only way I know to guarentee that is by employing reliable messaging in one way or another, which only acknowledges requests once persisted in a durable store;