如果目标重新启动，则不会发送 Service Broker 消息答案

【问题标题】：Service Broker messages not being sent if target rebooted如果目标重新启动，则不会发送 Service Broker 消息
【发布时间】：2012-10-15 03:27:30
【问题描述】：

在高层次上，这是正在发生的事情：

我们有两个 SQL Server 2008 R2 SP1 系统（Windows NT 6.1 上的标准版（内部版本 7601：Service Pack 1））他们一直在嗡嗡作响，双向交流，没有错误或问题。
我们重新启动系统 #2，希望在系统 #2 不可用时发送给它的任何 Service Broker 消息都会在系统 #1 上排队，直到系统 #2 恢复。
系统 #2 重新启动，那里的一切正常启动，没有错误。
在系统 #1 上为系统 #2 排队的消息仍处于排队状态；他们永远不会被发送。此外，该对话中的新消息也会排队并且永远不会发送。
在新对话中发送的消息可以正常传输。

关于从未发送的消息的详细信息：

A.当系统 #2 关闭时，队列中消息的传输状态显示各种错误，表明它无法与系统 #2 通信，如预期的那样。

B.在系统 #2 恢复后不久，这些消息的传输状态变为空白。在此之后，空白状态永远不会改变。

C.消息堆积的对话处于 CONVERSING/CO 状态。系统视图中没有任何列表明与其他正常工作的队列有任何不同。（如果我能找到任何设置不同的标志，我会知道终止糟糕的对话，但系统没有提供任何线索——除了不断增长的队列深度。）

D.在系统 #2 上永远不会收到这些消息，因为这些消息永远不会调用我的激活存储过程。

E.在 Profiler 中（打开所有 Broker 跟踪类型），良好的对话显示这些内容被记录：

Broker:Conversation CONVERSING  1 - SEND Message        Initiator                                       
Broker:Message Classify 2 - Remote  Initiator
[SQL Batch complete; SQL that caused the SEND to occur]
Broker:Remote Message Acknowledgement   1 - Message with Acknowledgement Sent   Initiator
Broker:Message Classify     1 - Local   Initiator
Broker:Conversation CONVERSING  6 - Received Sequenced Message  Target
Broker:Remote Message Acknowledgement   3 - Message with Acknowledgement Received       Initiator
Broker:Activation       Microsoft SQL Server Service Broker Activation  1 - Start

发送的注定会卡住的消息仅显示前两个事件：

Broker:Conversation CONVERSING  1 - SEND Message    Initiator
Broker:Message Classify 2 - Remote  Initiator

据我所知，这就是这些消息的全部内容。没有迹象表明 SQL Server 会再次尝试传输它们。系统#1 认为对话还不错，但系统#2 完全忘记了。系统#1 似乎永远无法解决这个问题。如果我们随后重新启动系统 #1，那么一切都会恢复正常，所有消息都按预期流动。

我认为这些消息实际上已经发送，但确认并没有返回到系统 #1。但我没有看到任何备份确认队列的证据。

我们检查了双方的许多典型问题：

双方都启用了代理。 2. 所有队列都打开，所有适当的东西都启用（入队、接收）。队列没有中毒。 3. 不存在我们所知道的权限问题。 4. 我们没有使用即发即弃。 5. 我们正在重用对话，正如许多人所建议的那样。（事实上，对话重用是这里的问题！） 6.我们正在捕获SQL异常，按照指示使用事务等。 7. ssbdiagnose 不返回错误。

当 SQL Server 主机重新启动时，我们预计任何排队的消息最终都会被发送，但事实并非如此。这是怎么回事？？

【问题讨论】：

您能否在目标机器上附加 Profiler 以查看重启后发生的情况？错误应该被提出来。
您还应该尝试收听“安全审计 --> 审计代理对话”和“安全审计 --> 审计代理登录”事件。请确保你在两边都这样做。此外，有趣的是，SSBDiagnose.exe 没有检测到任何 SSB 配置问题。
我看到代理在重新启动或不工作时出现了多个问题。最后决定使用普通队列，在队列中插入一条记录，使用消息代理发送队列项id。然后我还写了一个周期性队列处理程序。因此，在 99% 的情况下，消息代理一切正常，在 1% 的情况下，我错过了消息，（基于时间的）队列处理程序将其捡起。
你有激活存储过程来处理消息吗？
我认为将其发布/迁移到 SE 数据库管理员页面会更好。 dba.stackexchange.com

标签： sql-server service-broker

【解决方案1】：

我知道这是一个相当古老的线程，但我之前遇到过完全相同的情况，在我的情况下，网络配置是罪魁祸首。

由于某种原因，发起者从一个 IP 地址发送了它的消息，但另一个 IP 已打开以接受传入的回复（并且第二个 IP 已在目标的路由中指定）。

我是偶然发现的，真的。当我试图在目标端结束对话时，它并没有关闭，但 EndDialog 消息出现在sys.transmission_queue 中，状态为：

连接尝试失败并出现错误：'10060（连接尝试失败，因为连接方没有正确响应后一段时间，或建立连接失败，因为已连接主机没有响应。）'。

我不知道为什么目标重启会触发故障，但是当网络工程师解决了问题并且我更改了目标的路线时，一切都按照从一开始就应该到达的目的地。

【讨论】：

仅供参考，这条错误消息将作为Broker:Connection Event Class 记录到配置文件中。 ssbdiagnose.exeRUNTIME 也应该捕获并报告此事件，可能还有更多诊断信息。
@RemusRusanu - 真可惜，当时我不知道这个工具。而且我们还尝试实现可重用的对话框，因此在目标端关闭它们看起来不是一件显而易见的事情。