One of my on-going projects uses a light weight client to call a web service, which runs a fairly long running process, part of which will take at minimum five minutes. Testing has proved that the request to the webserver will cause a timeout. I belive the default is about 90 seconds. There are probably many ways to circumvent this problem, but the two that i am concidering are:

• Increase the time out settings to cover the longest anticipated duration.
• To implement fire and forget by the client, and let the webservice spawn an additional thread to carry out the long process, returning the request almost imeadiatley.

Increasing Timeout settings

Solution

From a little web reasearch it appears that there are three settings that may be able to assist me.

• The timeout property on the webservice proxy
• The http-runtime setting in App.Config of the calling assembly
• The http-runtime setting in Web.Config of the webservice.

Pros

• Allows trapping of exceptions during the process and passing them back to the client in the form of a SoapException.

Cons

• Process time may vary over operational lifetime of project requiring changing of configuration files, and possibly recompliling everytime the threshold is exceeded.
• If the request times out there is no way of knowing if the process is still running.

Fire and Forget

Solution

My second solution would be to use the BackgroundWorker to spawn a new thread in the code called the from the WebService's WebMethod.

Pros

• Allows imediate return of the WebMethod request so very little risk of time out, and therefore virtually limit less total process time.
• Because the client needs to request whether the process has finished any way, if an exception occurs this can be handled and the status relayed back to the client at the next request.

Cons

• Requires state of progress or completion to be stored by webservice (in database, text file, or similar).
• Requires the calling client to keep "asking" the webservice if the task has finished. This will involve more coding and the client having to "know" that it has to keep asking for the progress and or status of completion of the task.
• Requires extra coding to provide client with information if an exception occurs during the process.

So which is the best method to choose? Well this is probably going to sound like a bit of a cop-out, but it really does depend upon the application and how it is to be used. Each solution has it merits and its drawbacks as you can see.

For the project that I am concerned with I will no doubt use the fire and forget solution so I am not limited to time outs, as one of the processes (Archiving) will gradually take longer and longer to complete over the working life of the application, and I do not wish to be having to change the timeout and recompile frequently. I am also concerned that the timeout required couls easily surpass acceptable limits.

So how would you choose to carry out this task? Do you have any other solutions? Can you see any more advanatages or disadvantages of using either of the two solutions presented? your thoughts are welcom as always.

To be continued...