【问题标题】:WCF Connections exceeding max connections when using Asynchronous pattern使用异步模式时 WCF 连接数超过最大连接数
【发布时间】:2010-10-01 19:52:53
【问题描述】:

我有一个简单的 WCF 服务,我正在与之异步通信。

我不喜欢的是打电话给EndServiceMethod(IASyncResult)

如果我忘记调用Close() 方法,服务实际上将保持连接打开,然后在 wcf 达到其最大并发连接数后所有剩余连接将失败,并出现超时异常。

我尝试过使用[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall)] 服务合同的属性,这似乎对来自服务的连接状态没有任何影响。

也许我实施不正确?

任何想法或建议。

我正在尝试为 WCF 找到一种行为模式,该模式允许客户端发出请求,然后服务器响应请求,然后假设连接已完成并且可以终止。

【问题讨论】:

    标签: c# wcf


    【解决方案1】:

    这实际上是一个棘手的问题。

    一方面,如果您不关闭连接,它将保持打开状态直到超时(1 分钟),在负载下您将达到最大连接数(默认为 10)。

    另一方面,您正在异步调用服务,因此如果您在收到回调之前关闭连接,则回调将丢失。

    您可以尝试以下几种方法:

    • 增加最大连接数
    • 在回调处理程序中关闭连接
    • 减少超时时间

    【讨论】:

    • 我一直在回调处理程序中关闭它,这似乎有效。我想我只是希望有一个更优雅的解决方案,让这项工作发生在服务器端。
    • 这实际上是最好的解决方案。根据您的代码,您可能能够计算回调处理程序的数量以及您调用 close 的次数并查看它们是否匹配。
    • 除了我将有很多客户端,每个客户端都可能有多个连接。公共 wcf 服务如何做到这一点?我无法想象他们希望他们的客户在完成连接后总是善于关闭连接。
    • @Beta033,公共服务将具有较高的最大连接数和较低的超时时间。
    • 我和你在一起@Beta033。我一直使用 basicHttpBindings 并且我发现,即使没有异步调用,wsHttpBinding 也会将连接打开 100 秒,直到客户端不调用 close 时超时。客户对服务器性能有这么大的发言权,这让我感到非常不舒服。我得出了同样的结论,你所能做的就是设置一个高最大值和尽可能低的超时时间。
    【解决方案2】:

    指定 Windows Communication Foundation (WCF) 服务的限制机制。

    http://msdn.microsoft.com/en-us/library/ms731379%28v=VS.90%29.aspx

    【讨论】:

      【解决方案3】:

      我不知道这是否有帮助:

      您可以设置绑定,以便

      • 安全设置为无
      • 可靠的会话被禁用

            <wsHttpBinding>
                <binding name="MyWsHttpBinding">
                    <reliableSession enabled="false"/> 
                    <security mode="None" />
                </binding>
            </wsHttpBinding>
        

      我发现通过这样做我可以打开无限数量的频道并“忘记”关闭它们。

      那么您必须询问这是否适合您的情况。

      【讨论】:

        【解决方案4】:

        我不会将异步模式与 WCF 一起使用。相反,我只会使用带有正常 using 块的同步调用来确保连接已关闭。然后我会将整个混乱包装在一个普通的 Task (.NET 4.0) 或 ThreadPool 工作项中。

        【讨论】:

        • 我开始确信使用工作线程中包装的同步 wcf 调用将成为模拟异步通信的方式。谢谢。
        • 在任何有状态通道上进行同步调用后,您仍然必须调用Close
        【解决方案5】:

        在您不再需要时关闭任何类型的连接只是开发人员的基本职责。没有什么可抱怨的。关闭连接,您将不会遇到此问题。试图以任何其他方式解决丢失的关闭呼叫是无稽之谈。

        【讨论】:

        • 我认为你没有抓住重点。关键是允许服务器处理这个问题,而不是强迫客户端维护它。这样,灾难性的通信故障不会使服务器上的连接保持打开状态并占用一个插槽。
        • 不,我不是。异步调用不会取代关闭连接的需要。顺便提一句。您提到 PerCall 实例化对您不起作用。您使用的是哪种绑定? PerCall 实例化仅适用于不使用传输、可靠或安全会话的绑定。
        猜你喜欢
        • 2015-05-24
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2013-04-20
        • 1970-01-01
        • 1970-01-01
        • 2020-11-08
        • 2014-06-22
        相关资源
        最近更新 更多