WCF 服务的工作流意外停止

发布于 2024-08-23 06:36:03 字数 398 浏览 4 评论 0原文

我们有一个作为服务托管的 .Net 3.5 工作流,有时会意外停止。在写入文件时以及最近收到来自另一个 WCF 服务的回复时,有时会发生这种情况。没有捕获任何异常,因为这些都被记录下来,并且托管两者的服务器上的事件日志中没有消息。我添加了日志记录来验证服务是否正在完成其逻辑(大约需要 6 分钟)。我所有的超时都远远高于他们需要的。我开始认为问题可能是通道正在关闭,并且由于超时时间非常长,尚未引发错误。具有潜在相关性的是,工作流异步调用 wcf 服务,然后在 AsyncWaitHandle 上使用 WaitOne()。我有一种感觉,这可能不是最好的主意,但我不确定它是否会导致这个问题。另外,工作流上没有设置持久性(我之前认为 unloadOnIdle 设置可能会导致从被调用服务获取返回值时出现问题,因为我不太清楚这是如何工作的)。

任何帮助/建议将不胜感激。

We have a .Net 3.5 Workflow hosted as a service that sometimes stops unexpectedly. This has occurred at times while it is writing a file and, most recently, when receiving a reply from another WCF service. There are no exceptions being caught, as these all get logged, and there are no messages in the event logs on the server where both are hosted. I added logging to verify that the service is completing it's logic, which it is (taking about 6 minutes). All my timeouts are far higher than they need be. I'm starting to think the issue might be that the channel is getting closed and, due to the very high timeouts, an error is not yet thrown. Of potential relevance, the workflow is calling the wcf service asynchronously and then using a WaitOne() on the AsyncWaitHandle. I have a feeling this is maybe not the best idea, but I'm not sure if it could cause this issue. Also, persistence is not set up on the workflow (I had previously thought that the unloadOnIdle setting might have been causing issues with getting return values from the called service, as I'm not very clear on how this is supposed to work).

Any help/advice would be greatly appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

寒冷纷飞旳雪 2024-08-30 06:36:03

您检查过客户端的超时设置吗?我知道过去我必须更新客户端超时设置以及服务器设置。

Have you checked the timeout settings on the client. I know in the past I had to update both the client timeout settings as well as the server settings.

童话里做英雄 2024-08-30 06:36:03

在工作流 App.config 中(缺少工作流托管超时?):

<bindings>
  <basicHttpBinding>
    <binding name="BasicHttpBinding_IService" closeTimeout="00:02:00"
      openTimeout="00:02:00" receiveTimeout="04:00:00" sendTimeout="04:00:00"
      allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
      maxBufferSize="655360000" maxBufferPoolSize="2147483647" maxReceivedMessageSize="655360000"
      messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
      useDefaultWebProxy="true">
      <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
      <security mode="None">
        <transport clientCredentialType="None" proxyCredentialType="None"
          realm="" />
        <message clientCredentialType="UserName" algorithmSuite="Default" />
      </security>
    </binding>
  </basicHttpBinding>
</bindings>
<client>
  <endpoint address="http://url/Service.svc"
    binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IService"
    contract="DALService.IService" name="BasicHttpBinding_IService" />
</client>

在 DalService WCF web.config 中:

<httpRuntime
    maxRequestLength="1048576"
    executionTimeout="6000000"
/>
<basicHttpBinding>
<binding name ="LargeMessageBinding"
          closeTimeout="00:01:00"
          openTimeout="00:01:00" receiveTimeout="04:30:00" sendTimeout="04:30:00"
          allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
          maxBufferSize="655360000" maxBufferPoolSize="524288" maxReceivedMessageSize="655360000"
          messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
          useDefaultWebProxy="true"
         />
<!--maxReceivedMessageSize="6553600" -->
<!--maxBufferSize="6553600" -->

In the workflow App.config (missing a timeout for the hosting of the workflow?):

<bindings>
  <basicHttpBinding>
    <binding name="BasicHttpBinding_IService" closeTimeout="00:02:00"
      openTimeout="00:02:00" receiveTimeout="04:00:00" sendTimeout="04:00:00"
      allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
      maxBufferSize="655360000" maxBufferPoolSize="2147483647" maxReceivedMessageSize="655360000"
      messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
      useDefaultWebProxy="true">
      <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
      <security mode="None">
        <transport clientCredentialType="None" proxyCredentialType="None"
          realm="" />
        <message clientCredentialType="UserName" algorithmSuite="Default" />
      </security>
    </binding>
  </basicHttpBinding>
</bindings>
<client>
  <endpoint address="http://url/Service.svc"
    binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IService"
    contract="DALService.IService" name="BasicHttpBinding_IService" />
</client>

In the DalService WCF web.config:

<httpRuntime
    maxRequestLength="1048576"
    executionTimeout="6000000"
/>
<basicHttpBinding>
<binding name ="LargeMessageBinding"
          closeTimeout="00:01:00"
          openTimeout="00:01:00" receiveTimeout="04:30:00" sendTimeout="04:30:00"
          allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
          maxBufferSize="655360000" maxBufferPoolSize="524288" maxReceivedMessageSize="655360000"
          messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
          useDefaultWebProxy="true"
         />
<!--maxReceivedMessageSize="6553600" -->
<!--maxBufferSize="6553600" -->

日裸衫吸 2024-08-30 06:36:03

事实证明,工作流程并没有像我想象的那样托管在它自己的工作进程中。另一个应用程序导致进程崩溃。 WCF 服务已正确配置为使用其自己的工作进程,因此它将正确返回,但返回到不再运行的应用程序。

Turns out, the workflow was not being hosted in its own worker process, as I had thought. Another app was crashing the process. The WCF service was correctly configured to use its own worker process, hence it would correctly return, but to a no longer running app.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文