Windows 事件日志中的虚假 MSMQ 超时错误
我有一个 Windows 服务，它轮询 MSMQ 队列并将传入消息分派给处理程序。当我希望服务关闭时，它不会关闭，除非我强制队列的接收在一段时间后超时。如果我不这样做，Windows 服务控制器将无法终止该服务（并且我还需要测试我的安装程序）。实际上这不会成为问题，因为队列的负载会很重。但在我的开发环境中，我的事件日志中收到了许多虚假的错误条目。例如：
while (!Signal)
{
try
{
var msg = Queue.Receive(TimeSpan.FromSeconds(1));
if (Signal)
{
EventLog.WriteEntry("LoggingHub",
"Terminating QueueReader for Path [" +
Queue.Path + "]", EventLogEntryType.Information);
return;
}
// etc etc etc
有没有办法让我关闭错误报告，因为我认为这是对 Receive 函数的合法使用？
I've a Windows service that polls an MSMQ Queue and dispatches incoming messages to handlers. When I want the service to shutdown it won't, unless I force the Queue's Receive to timeout after some period of time. If I don't the windows service controller will not be able to terminate the service (& I also need to test my installer). In practice this won't be a problem because the Queue will be heavily loaded. But in my Dev environment, I get numerous spurious Error entries in my event log. For instance:
while (!Signal)
{
try
{
var msg = Queue.Receive(TimeSpan.FromSeconds(1));
if (Signal)
{
EventLog.WriteEntry("LoggingHub",
"Terminating QueueReader for Path [" +
Queue.Path + "]", EventLogEntryType.Information);
return;
}
// etc etc etc
Is there a way for me to turn off the error reporting, since I see this as a legitimate use of the Receive function?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
最后我放弃了超时方法，转而使用异步回调 - 使用 BeginReceive 和 EndReceive。我可以立即停止服务，避免无谓地使用宝贵的资源。
FWIW：我同意 @John Breakwell 的观点，这应该是一个合法的使用场景，但如果它在您的事件日志中填充了虚假错误，那么它实际上毫无价值。我只能假设 API 变体仅适用于当您期望在确定的时间范围内发生事件（即 ACK 或类似事件）时，因此可以将超时解释为协议错误。
In the end I abandoned the timeout approach in favour of asynchronous callbacks - using BeginReceive and EndReceive. I am able to stop the service immediately, and refrain from using precious resources pointlessly.
FWIW: I agree with @John breakwell that that ought to be a legit usage scenario, but it is effectively worthless if it fills your event log up with spurious errors. I can only assume that the API variant is intended solely for when you expect an event within a definite timeframe (i.e. an ACK or similar) and can thus interpret a timeout as a protocol error.