怎么知道wcf服务的状态

[Zanvimocvy]

客户端和服务端采用wcf通信。用的是basicHttpBinding和netTcpBinding和协议。
因为客户端和服务端的连接有时会断开，有时是服务停止，有时是服务处于假死状态。假死的时候，服务是开启的，但是客户端就是连不上，只有重启服务才会正常。
现在我想获取到wcf服务和客户端连接的状态，如果wcf服务出现了问题，就重启服务，保证客户端能正常运行。wcf服务断开，相信大家也遇到过，不知道做过wcf服务方面的大神们都是用什么方式解决的

[以专业开发人员为伍]

我们解决 WCF 在并发时特别容易失败的问题的做法，就是：“不用WCF，使用基本的 http post/get 的 ashx 即可”。

[IE11下面经常卡到爆]

在服务中加个专门用来获取服务状态的接口和方法呗 但那并不能实际解决问题，你的服务肯定存在某方面的。如果你的服务设置为单例，偶尔假死还说的过去，但如果超过请求时间还在假死就不正常了

[Zanvimocvy]

引用 5 楼 duanzi_peng 的回复:

[quote=引用 3 楼 dongxinxi 的回复:] 在服务中加个专门用来获取服务状态的接口和方法呗 但那并不能实际解决问题，你的服务肯定存在某方面的。如果你的服务设置为单例，偶尔假死还说的过去，但如果超过请求时间还在假死就不正常了

是的，目前 单例模式下 还没有遇到过假死的情况。[/quote] 我没遇到你们说的这种情况。请求超时处于假死状态。服务他也不可能是单例呀

[Zanvimocvy]

引用 3 楼 dongxinxi 的回复:

在服务中加个专门用来获取服务状态的接口和方法呗 但那并不能实际解决问题，你的服务肯定存在某方面的。如果你的服务设置为单例，偶尔假死还说的过去，但如果超过请求时间还在假死就不正常了

服务状态的接口和方法怎么获取

[exception92]

引用 3 楼 dongxinxi 的回复:

在服务中加个专门用来获取服务状态的接口和方法呗 但那并不能实际解决问题，你的服务肯定存在某方面的。如果你的服务设置为单例，偶尔假死还说的过去，但如果超过请求时间还在假死就不正常了

是的，目前 单例模式下 还没有遇到过假死的情况。

[wanghui0380]

这个倒是有意思，其实wcf没有关系 1.心跳维持，空置tcp。会没事被路由掐掉，路由要复用端口，你长时间占着又不吭气，他会T掉你 2.假死什么，单例什么都不是问题。跟wcf没关系和restfull也没关系，那叫不响应，那是自己得代码问题。而且可以任何问题，你死锁了可以，你一个同步代码就在那里卡着可以，你一个线程挂了，然后依赖项连锁响应都挂了，任何能导致无响应得都可以导致问题。 哪怕是java们一样头疼，java可没有wcf把。但是你看java们最近在干什么，最近得主流项目是什么？日志采集，服务监控，状态监控，自动重启服务，自动排程扩展docker和群集---------为啥，他们也挂，他们也会无响应，他们也会卡死，能解决得早解决了，解决不了怎么办。和你一样重启服务，只不过人家研究的是怎么自动监控，自动重启，自动分析日志和状态和资源，自动扩展资源

[Zanvimocvy]

引用 8 楼 wanghui0380 的回复:

这个倒是有意思，其实wcf没有关系 1.心跳维持，空置tcp。会没事被路由掐掉，路由要复用端口，你长时间占着又不吭气，他会T掉你 2.假死什么，单例什么都不是问题。跟wcf没关系和restfull也没关系，那叫不响应，那是自己得代码问题。而且可以任何问题，你死锁了可以，你一个同步代码就在那里卡着可以，你一个线程挂了，然后依赖项连锁响应都挂了，任何能导致无响应得都可以导致问题。 哪怕是java们一样头疼，java可没有wcf把。但是你看java们最近在干什么，最近得主流项目是什么？日志采集，服务监控，状态监控，自动重启服务，自动排程扩展docker和群集---------为啥，他们也挂，他们也会无响应，他们也会卡死，能解决得早解决了，解决不了怎么办。和你一样重启服务，只不过人家研究的是怎么自动监控，自动重启，自动分析日志和状态和资源，自动扩展资源

确实，解决不了的就是要重启，是一个很重要的方法。当时也确实是这样做的，但是有时自动重启了，会有一定几率导致服务漏收消息（虽然重启半分钟内完成）