views:

84

answers:

1

I have created a test service with a method that contains a very long loop. I was hoping that when a timeout transaction occurs, the method execution will flush, but it doesn't. The client gets a timeout, but the processing continues on the server.

Is there way to stop it? Without changing the method code?

Here is the example: in the example I call the method QueueRequest using queue binding, and after 10 seconds the transaction is aborted. At this point a retry occurs, causing the same issue. After a few retries the server is doing 100% cpu work trying to ran the loop on multiple threads / instances even if the message is poison and dropped.


  // NOTE: If you change the class name "Service1" here, you must also update the reference to "Service1" in App.config.
   [ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall, 
      TransactionTimeout="00:00:10",
      ReleaseServiceInstanceOnTransactionComplete=true)]
   [ErrorHandlingBehaviorAttribute]
   public class Service1 : IQueueService
   {
      public Service1()
      {
         Trace.WriteLine("Creating an instance on thread " + Thread.CurrentThread.ManagedThreadId.ToString());
      }

      ~Service1()
      {
         Trace.WriteLine("Destroying an instance on thread " + Thread.CurrentThread.ManagedThreadId.ToString());
      }


      [OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true)]
      public void QueueRequest(string message)
      {
         int id = Thread.CurrentThread.ManagedThreadId;
         Trace.WriteLine("Got Message on thread " + id.ToString());
         for (int i = 0; i < 1000000; i++)
         {
            Trace.WriteLine("Processing " + i.ToString() + " Thread ID " + id.ToString());
            Thread.Sleep(1000);        
         }
      }
   }
+1  A: 

I don't think that this is possible without modifying your existing code.

Take a look here and here. The thread servicing the request is totally decoupled from the part of WCF which delivers the results to the client.

David Kirkland
Thanks. for the information.