【问题标题】：Why would a Service Broker Receive take longer than the specified timeout?为什么 Service Broker 接收需要比指定的超时时间更长的时间？
【发布时间】：2011-10-18 12:39:11
【问题描述】：
我正在编写一个使用 SQL Server Service Broker 的高负载应用程序。我已经到了在 Management Studio 中运行以下脚本需要 1 分 6 秒的状态，即使在我停止了应用程序之后也是如此。什么可能导致它需要这么长时间？我以为 TIMEOUT 会让它在半秒后停止？
WAITFOR (RECEIVE TOP(1) * FROM [targetqueuename]), TIMEOUT 500;
SELECT @@ERROR;
@@ERROR 返回 0。在第一次运行这么长时间后，后续运行会立即返回。
【问题讨论】：
标签：
tsql
sql-server-2008
service-broker
【解决方案1】：
WAITFOR(RECEIVE), TIMEOUT 通过实际运行至少一次 RECEIVE 来工作。如果结果集为空，则继续等待。每次它认为它可以成功时（它在内部收到更多消息可用的通知）它再次运行 RECEIVE。在循环中重复，直到它返回行或超时。
但超时不会中断已经在此循环内执行的 RECEIVE。如果 RECEIVE 需要很长时间才能在队列中查找消息（可能发生在大型队列或 RECEIVE 执行计划错误的情况下），则无法兑现超时。请注意，即使 RECEIVE 确实没有找到任何消息，情况也可能如此，因为队列可能包含大量全部锁定的消息（更准确地说，所有消息都属于锁定的会话组）。在这种情况下，RECEIVE 可能需要很长时间才能执行，搜索未锁定的对话组，最后仍然空手而归。