3

based on customer requirement i realized a C# WCF web service that on each invocation starts a thread that performs asynchronous processing of its own. Once the thread is started, the web service ends its execution normally, regardless of the state of thread processing.

The problem i have is that sometimes, not always, the thread is interrupted randomly without any exception. The interruption takes place at different points and at different times so i am not able to identify a constant in its malfunction.

I report the piece of code of the service that starts the thread.

//WCF starts
....
//Starts a new thread
System.Threading.ThreadPool.QueueUserWorkItem(th =>
{

    ThreadContext.Properties["property1"] = prop1;

    // The class to be executed by the thread
    ExecutionClass executionClass= new ExecutionClass();

    Logger.log("start elaboration");       

    executionClass.start(parameter);
});
....
// the WCF returns the response independently of thread execution
return response;

May It be the windows or IIS that is causing thread ending? Can i do anything to fix this?

P.S. I know that is not a good solution to be implemented, but the requirements were imposed by the client.

VMAtm
  • 27,943
  • 17
  • 79
  • 125
Alessandro
  • 137
  • 3
  • 14

3 Answers3

2

Your code doesn't start a new Thread. It does start a new unit-of-work so the ThreadPool can run your work inside already created thread.
Will your customer be satisfied if you'll start a Task instead of a UserWorkItem? You can run it in a default ThreadPool, so the behaviour of your application will be exactly the same, but you can easily attach to continuation of the task for the exception handling, so you'll be always aware about the unfinished tasks in your code. You can even provide a flag for ThreadPool that this task will be a long running one, so this will reduce the kills of the threads.

with Run method

Task.Factory.Run(() =>
{
    ThreadContext.Properties["property1"] = prop1;

    // The class to be executed by the thread
    ExecutionClass executionClass= new ExecutionClass();

    Logger.log("start elaboration");       

    executionClass.start(parameter);
// TaskScheduler.Default is used by default to run your code in ThreadPool
})
// handle the thread aborting appropriately
.ContinueWith(t =>  
  HandleException(task.Exception),
  // no code if task is success or canceled
  TaskContinuationOptions.OnlyOnFaulted);

with StartNew method with LongRunning parameter:

Task.Factory.StartNew(() =>
{
    ThreadContext.Properties["property1"] = prop1;

    // The class to be executed by the thread
    ExecutionClass executionClass= new ExecutionClass();

    Logger.log("start elaboration");       

    executionClass.start(parameter);

}
// as you don't interested in the task's future, you don't need any cancellation token
, CancellationToken.None
// provide the long running parameter
, TaskCreationOptions.DenyChildAttach | TaskCreationOptions.LongRunning
// provide TaskScheduler.Default to run your code in the ThreadPool
, TaskScheduler.Default);)
// handle the thread aborting appropriately
.ContinueWith(t =>  
  HandleException(task.Exception),
  // no code if task is success or canceled
  TaskContinuationOptions.OnlyOnFaulted);

So links related:

Community
  • 1
  • 1
VMAtm
  • 27,943
  • 17
  • 79
  • 125
1

Look at the app pool (in IIS) for your site. There are a number of settings that affect the lifetime of the threads.

Anthony Horne
  • 2,522
  • 2
  • 29
  • 51
1

Thanks to all for your suggestions!

Finally I got the cause of the problem: when my web service calls other web services if it waits too long for the answer the thread get killed by IIS.

The reason, in my case, is that systems engineers have set a timeout value on IIS that aims to free the memory if the applications are in wait status for more than 120s.

Unfortunatly they can't change the value, but now I had the evidence of the problem so I am now free to change architecture.

VMAtm
  • 27,943
  • 17
  • 79
  • 125
Alessandro
  • 137
  • 3
  • 14