为什么 Service Broker 接收时间会比指定的超时时间长？
我正在编写一个使用 SQL Server Service Broker 的高负载应用程序。即使我停止了应用程序，在 Management Studio 中运行以下脚本也需要 1 分 6 秒。是什么导致需要这么长时间？我以为超时会让它在半秒后停止？
WAITFOR (RECEIVE TOP(1) * FROM [targetqueuename]), TIMEOUT 500;
SELECT @@ERROR;
@@ERROR 返回 0。第一次运行花了这么长时间后，后续运行将立即返回。
I'm writing a high load application that uses SQL Server Service Broker. I have got to a state where running the following script in Management Studio takes 1 minute 6 seconds, even after I have stopped the application. What could be causing it to take so long? I thought the TIMEOUT would make it stop after half a second?
WAITFOR (RECEIVE TOP(1) * FROM [targetqueuename]), TIMEOUT 500;
SELECT @@ERROR;
@@ERROR is returning 0. After the first run taking this long, subsiquent runs are returning instantly.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
WAITFOR(RECEIVE), TIMEOUT的工作原理是至少实际运行一次 RECEIVE。如果结果集为空，则继续等待。每当它相信它可以成功时（它在内部收到有更多消息可用的通知），它就会再次运行 RECEIVE。循环重复，直到返回行或超时。但超时不会中断已在该循环内执行的 RECEIVE。如果 RECEIVE 需要很长时间才能在队列中查找消息（可能会发生在大型队列或 RECEIVE 执行计划错误的情况下），则无法遵守超时。请注意，即使 RECEIVE 没有找到任何消息，也可能出现这种情况，因为队列可能包含大量全部锁定的消息（更准确地说，所有消息都属于锁定的会话组）。在这种情况下，RECEIVE 可能需要很长时间才能执行，搜索未锁定的会话组，但最终仍然空手而归。
WAITFOR(RECEIVE), TIMEOUTworks by actually running the RECEIVE at least once. If the result set is empty, it continues to wait. Every time it believes that it can succeed (it gets notified internally that more messages are available) it runs the RECEIVE again. Repeat in a loop until either it returns rows or it times out.But the timeout does not interrupt a RECEIVE already executing inside this loop. If the RECEIVE is taking long to find messages in the queue (can happen with large queues or with bad execution plans for RECEIVE) then the timeout cannot be honored. Note that this can be the case even if the RECEIVE does not find any message, since the queue may contain a large number of messages all locked (more precisely all belonging to locked conversation groups). In this case the RECEIVE may take a long time to execute, searching for unlocked conversation groups and in the end still come empty handed.