具有多个线程的WCF服务

本文介绍了具有多个线程的WCF服务的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我在IIS 6.0/win 2003计算机下托管了一个wcf服务.服务具有这样的方法.

I have a wcf service hosted under IIS 6.0/win 2003 machine. Service has a method like this.

    List<CustomObject> ProcessImageData(List<CustomObject> lstData)
    {
          lstSharedProcessedImages = lstData;

         for (int idx = 0; idx < lstData.Count; )
         {
            CurrentThreadRoom = MAX_THREAD_COUNT - ThreadRunningCount;
            for (int ctr = 0; ctr < CurrentThreadRoom; ctr++)
            {
                runBrowserThread(lstData[idx].Url, lstData[idx].Path);
                idx++;
                if (lstData.Count == idx)
                    break;
            }
            while (ThreadRunningCount >= MAX_THREAD_COUNT)
            {
                Thread.Sleep(SleepTimeMiliseconds);
            }
        }
        while (ThreadRunningCount > 0)
        {
            Thread.Sleep(SleepTimeMiliseconds);
        }
        return lstSharedProcessedImages;
    }

web.Config(服务)文件

    <service behaviorConfiguration="WcfServices.Service1Behavior" name="WcfServices.HtmlToImageService">
    <endpoint address="" binding="wsHttpBinding" bindingConfiguration="LargeSizeMessages" contract="WcfServices.IHtmlToPngService">
      <identity>
        <dns value="localhost"/>
      </identity>
    </endpoint>
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
   </service>

    <behaviors>
    <serviceBehaviors>
    <behavior name="WcfServices.Service1Behavior">
      <serviceThrottling maxConcurrentCalls="1000" maxConcurrentSessions="1000" maxConcurrentInstances="1000"/>
      <serviceMetadata httpGetEnabled="true"/>
      <dataContractSerializer maxItemsInObjectGraph="6553500"/>
      <serviceDebug includeExceptionDetailInFaults="true"/>
    </behavior>
   </behaviors>

客户端的app.config文件

    <wsHttpBinding>
      <binding name="WSHttpBinding_IHtmlToImageService" closeTimeout="00:10:00"
      openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:10:00"
      bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
      maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647"
      messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
      allowCookies="false">
      <readerQuotas maxDepth="32" maxStringContentLength="2147483647"
        maxArrayLength="2147483647" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
      <reliableSession ordered="true" inactivityTimeout="00:10:00"
        enabled="false" />
      <security mode="Message">
        <transport clientCredentialType="Windows" proxyCredentialType="None"
          realm="" />
        <message clientCredentialType="Windows" negotiateServiceCredential="true"
          algorithmSuite="Default" />
      </security>
    </binding>
    </wsHttpBinding>

只有一个客户端循环调用wcf服务的方法，并等待一分钟，以便每次迭代接收结果. wcf服务产生10个线程(全部独立且彼此不依赖)来满足每个请求.这些线程中的每个线程都创建一个WebBrowser实例来完成其工作.处理请求并将响应发送回客户端通常需要6-7秒.大约80％的电话成功.

only one client calls the wcf service's method in a loop and wait one minute for each iteration to receive the results. The wcf service spawns 10 threads (all independent and NOT relying on each other) to fulfill each request. Each one of these threads creates a WebBrowser instance to do its job. It usually takes 6-7 seconds to process the request and send a response back to client. Around 80% of the calls are successful.

现在的问题是，

在Web服务器上，当客户端调用service方法时，我们看到线程数量激增(从13k总数增加到18k左右).该服务应该创建10个线程/请求，并且没有特定的代码可以在完成时终止线程.假设线程在完成给定的工作后就会自行死亡(还会释放内存等).

On the web server we see a huge spike in the number of threads (from 13k total to around 18k) when client calls the service method. The service is supposed to create 10 threads/request and there is no specific code which'd terminate the thread when it is done. Assumption is that thread dies its own death (also release memory etc.) as soon as the job given is complete.

由于某种原因，内存中剩余大量线程，这导致服务器无响应.还不确定为什么#of线程会出现如此之大的峰值.

For some reason, A lots of threads remains in the memory which makes server non-responsive. Also not sure why such a huge spike in the #of threads.

然后，对服务器的所有后续调用均失败.客户端不断发出新请求并继续出现以下异常.

Then all subsequent calls to server fails. Client keeps calling with new requests and continues to have the following exceptions.

这也可能是由于服务器终止了HTTP请求上下文(可能是由于服务关闭)."，请求通道在00:00:59.9749975之后等待答复时超时."等等等等...

"This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down).", "The request channel timed out while waiting for a reply after 00:00:59.9749975." etc etc...

当内存被重新收集并且线程数再次减少到13k左右时，服务又恢复了功能，进程请求，线程数量激增，新异常和恶性循环继续.

when the memory is recollected and thread count is again down to 13k or something, service becomes functional again, process request, # of thread spikes up, new exceptions and the vicious circle continues.

这里出了什么问题?假定内存中的#of个线程是罪魁祸首，如何强制在服务器上进行清理?线程清理似乎仍在发生，但为时已晚，因为那时异常过多.

What is going wrong here ?? Assuming the #of threads in memory is the culprit, how can I force the clean up on the server ? thread clean up appears to be happening anyway but too late cuz too many exceptions by then.

你们有什么建议?非常感谢任何输入！！！

what you guys suggest ? Highly appreciate any input !!!