从 WCF 中的 CommunicationObjectFaultedException 中恢复

发布于 2024-07-29 21:55:53 字数 435 浏览 6 评论 0原文

我有一个客户端应用程序,每 10 秒尝试通过 WCF Web 服务发送一条消息。 该客户端应用程序将安装在船上的计算机上,我们知道船上的互联网连接不稳定。 我希望应用程序尝试通过服务发送数据,如果不能,则对消息进行排队,直到可以通过服务发送它们。

为了测试此设置,我启动了客户端应用程序和 Web 服务(都在我的本地计算机上),一切正常。 我尝试通过终止网络服务并重新启动它来模拟糟糕的互联网连接。 一旦我终止该服务,我就开始收到 CommunicationObjectFaultedExceptions——这是预期的。 但在我重新启动服务后,我继续收到这些异常。

我很确定我对 Web 服务范例有些不理解,但我不知道那是什么。 任何人都可以提供有关此设置是否可行的建议,如果可行,如何解决此问题(即重新建立与 Web 服务的通信通道)?

谢谢!

克莱

I have a client app that tries every 10 seconds to send a message over a WCF web service. This client app will be on a computer on board a ship, which we know will have spotty internet connectivity. I would like for the app to try to send data via the service, and if it can't, to queue up the messages until it can send them through the service.

In order to test this setup, I start the client app and the web service (both on my local machine), and everything works fine. I try to simulate the bad internet connection by killing the web service and restarting it. As soon as I kill the service, I start getting CommunicationObjectFaultedExceptions--which is expected. But after I restart the service, I continue to get those exceptions.

I'm pretty sure that there's something I'm not understanding about the web service paradigm, but I don't know what that is. Can anyone offer advice on whether or not this setup is feasible, and if so, how to resolve this issue (i.e. re-establish the communications channel with the web service)?

Thanks!

Klay

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

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

发布评论

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

评论(1

谁人与我共长歌 2024-08-05 21:55:54

客户端服务代理一旦出现故障就无法重复使用。 您必须处理掉旧代理并重新创建一个新代理。

您还必须确保正确关闭客户端服务代理。 WCF 服务代理可能会在关闭时引发异常,如果发生这种情况,则连接不会关闭,因此您必须中止。 使用“try{Close}/catch{Abort}”模式。 另请记住,dispose 方法调用 close(因此可能会从 dispose 中抛出异常),因此您不能仅使用与普通一次性类类似的 using 。

例如:

try
{
    if (yourServiceProxy != null)
    {
        if (yourServiceProxy.State != CommunicationState.Faulted)
        {
            yourServiceProxy.Close();
        }
        else
        {
            yourServiceProxy.Abort();
        }
    }
}
catch (CommunicationException)
{
    // Communication exceptions are normal when
    // closing the connection.
    yourServiceProxy.Abort();
}
catch (TimeoutException)
{
    // Timeout exceptions are normal when closing
    // the connection.
    yourServiceProxy.Abort();
}
catch (Exception)
{
    // Any other exception and you should 
    // abort the connection and rethrow to 
    // allow the exception to bubble upwards.
    yourServiceProxy.Abort();
    throw;
}
finally
{
    // This is just to stop you from trying to 
    // close it again (with the null check at the start).
    // This may not be necessary depending on
    // your architecture.
    yourServiceProxy = null;
}

有一篇 博客文章关于此,但现在似乎已离线。 存档版本可用 在 Wayback Machine 上。

Client service proxies cannot be reused once they have faulted. You must dispose of the old one and recreate a new one.

You must also make sure you close the client service proxy properly. It is possible for a WCF service proxy to throw an exception on close, and if this happens the connection is not closed, so you must abort. Use the "try{Close}/catch{Abort}" pattern. Also bear in mind that the dispose method calls close (and hence can throw an exception from the dispose), so you can't just use a using like with normal disposable classes.

For example:

try
{
    if (yourServiceProxy != null)
    {
        if (yourServiceProxy.State != CommunicationState.Faulted)
        {
            yourServiceProxy.Close();
        }
        else
        {
            yourServiceProxy.Abort();
        }
    }
}
catch (CommunicationException)
{
    // Communication exceptions are normal when
    // closing the connection.
    yourServiceProxy.Abort();
}
catch (TimeoutException)
{
    // Timeout exceptions are normal when closing
    // the connection.
    yourServiceProxy.Abort();
}
catch (Exception)
{
    // Any other exception and you should 
    // abort the connection and rethrow to 
    // allow the exception to bubble upwards.
    yourServiceProxy.Abort();
    throw;
}
finally
{
    // This is just to stop you from trying to 
    // close it again (with the null check at the start).
    // This may not be necessary depending on
    // your architecture.
    yourServiceProxy = null;
}

There was a blog article about this, but it now appears to be offline. A archived version is available on the Wayback Machine.

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