Windows服务重连策略
我目前正在开发 Windows 服务(我的第一个服务),我想知道如何处理断开连接事件等。本质上,此 Windows 服务会轮询我们的 Exchange 服务器以查找新电子邮件。收到电子邮件后,我们对其进行解析并将其插入数据库。现在,只要一切都对我有利,我就一切顺利。由于这是不可能维护的,所以我需要寻找方法来确保我的服务保持在线,无论发生什么超出我的控制(减去托管服务的服务器)。
我可以预见的主要问题是我们的 Exchange 服务器由于某种原因而停机或失去互联网连接。这两个问题一年可能会发生几次。
目前,如果抛出有关连接问题的异常,我会每隔 n 分钟尝试连接一次,超时时间为 30 秒。假设我们的 Exchange 服务器停机(计划内维护或不可预见的事件)2 小时,那么服务将尝试每 n 分钟重新连接,直到建立连接。
这是确保我的服务始终保持在线的可持续策略吗?如果没有,有什么更好的方法?
我想避免的是我的服务出现故障,因为 Exchange 出现问题,导致我必须手动重新启动 Windows 服务。
谢谢。
I'm currently working on a Windows service (my first) and I'm wondering how to handle disconnect events and the like. In essence, this Windows service polls our Exchange servers for new emails. Once an email is received we parse it and insert it into a database. Now, I have everything working so long as everything is working in my favour. Since that is impossible to maintain I need to look for ways to ensure my service stays on line regardless of what may happen that is out of my control (minus the server hosting the service that is).
The main issues I can foresee are our Exchange servers going down for whatever reason or losing internet connectivity. Two problems which can happen several times a year.
Currently, if an exception is thrown regarding connectivity issues I keep attempting to connect every n minutes with a 30 second time out. So say our Exchange servers go down (either planned maintenance or unforeseen events) for 2 hours then the service would try and reconnect every n minutes until a connection is made.
Is this a sustainable strategy to ensure my service always stays online? If not, what is a better way?
What I want to avoid is my service going down because Exchange had issues making me have to manually restart my Windows service.
Thank you.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
你的策略听起来是唯一实用的。
也许还值得考虑添加从服务远程查看事件日志的功能,以便您可以诊断当前不知道的问题。如果您真的很偏执,可以使用第二个“观察者”服务来定期检查主服务并报告它是否失败。
Your strategy sounds like the only thing that's practical.
It may also be worth considering adding the ability to view event logs from the service remotely so you can diagnose issues that you don't currently know about. If you're really paranoid, a second "watcher" service could be used to periodically check the primary service and report if it fails.