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

Question

从高层次来看,这是正在发生的事情:

1. 我们有两个SQL Server 2008 R2 SP1系统(Windows NT 6.1上的标准版(Build 7601:Service Pack 1)).它们很好地哼唱,双向通信,没有错误或问题.
2. 我们重启系统#2,期望在它不可用时发送给它的任何Service Broker消息将在系统#1上排队,直到系统#2重新启动.
3. 系统#2重新启动,一切都正常启动,没有错误.
4. 在系统#1上为系统#2排队的消息仍然排队等候; 它们永远不会被发送.此外,该对话的新消息也会排队,永远不会发送.
5. 在新会话上发送的消息传输得很好.

有关从未发送过的消息的详细信息:

A.当系统#2关闭时,队列中消息的transmission_status显示各种错误,表明它无法按预期与系统#2通信.

B.在系统#2重新启动后不久,这些消息的transmit_status变为空白.在此之后,空白状态永远不会改变.

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.我们不知道存在任何权限问题.我们没有使用"即发即忘".我们正在重复谈话,正如各种人推荐的那样.(实际上,会话重用是这里的问题!)6.我们正在捕获SQL异常,使用事务按指示等.7.ssbdiagnose不返回任何错误.

重新启动SQL Server主机时,我们希望最终会发送任何排队的消息,但事实并非如此.这里发生了什么？？

Answer 1

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

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

我真的是偶然发现了这一点。当我尝试结束目标端的对话时，它尚未关闭，但 EndDialog 消息出现，sys.transmission_queue状态为：

连接尝试失败，错误：“10060（连接尝试失败，因为连接方在一段时间后没有正确响应，或者建立的连接失败，因为连接的主机未能响应。）”。

我不知道为什么目标重新启动会引发故障，但是当网络工程师解决了问题并且我更改了目标的路线时，所有东西都按照从一开始就假设的方式飞向了目的地。