Troubleshooting Service Broker: initiator database stuck CONVERSING/NOTIFIED

|▌冷眼眸甩不掉的悲伤 提交于 2020-01-02 09:58:26

问题


We are developing an application that will use service broker to transfer messages from one database to another. SourceDB is used by an existing application from which we are siphoning off some data. TargetDB is used only by this application and processes/distributes the data we need. We are only using one type of contract and both DBs are on the same server.

We have set up identical message types and contracts on both, and respective initiator and target queue/service. On both databases:

  • ENABLE_BROKER is set
  • TRUSTWORTHY is set
  • Have a unique service_broker_guid
  • Have sa as db owner, with all SSB authorization statements are dbo or OWNER, as appropriate.

However, when we send a message from SourceDB:

BEGIN DIALOG CONVERSATION @dialogHandle
    FROM SERVICE [//Service/Initiator]
    TO SERVICE N'//Service/Target'
    ON CONTRACT [//Contract/Notification]
    WITH ENCRYPTION = OFF;
SEND ON CONVERSATION @dialogHandle
    MESSAGE TYPE [//Message/Notification] (@RequestMsg);

...messages do not find their way there. Further investigation reveals the following:

  • The initiator queue is empty
  • The target queue is empty (NB: not an issue of needing to RECEIVE)
  • The transmission queue is empty
  • No errors are recorded, either in the SQL Server logs or in our CATCH error handling in the stored procedure that creates the message
  • The initiator queue's entry in SourceDB's sys.dm_broker_queue_monitors is set to NOTIFIED if activation is enabled
  • SourceDB's sys.conversation_endpoints has a new entry in CONVERSING state
  • The target queue's entry in TargetDB's sys.dm_broker_queue_monitors remains INACTIVE if activation is enabled
  • TargetDB's sys.conversation_endpoints has a new entry in CONVERSING state with the same conversation_id and different conversation_handle from SourceDB's entry

Although the test database is SQL 2005 (application must support 2005), I ran the ssbdiagnose utility from my development machine's 2008 installation to dianose the issue:

ssbdiagnose -S testserver -d SourceDB CONFIGURATION FROM SERVICE //Service/Initiator TO SERVICE //Service/Target ON CONTRACT //Contract/Notification

That produced the following:

D  29912 dbtestsvr  SourceDB  Service //Service/Target was not found
D  29975 dbtestsvr  SourceDB  User dbo does not have SEND permission on service //Service/Target

This is confusing, since dbo should not be denied any permission, and //Service/Target certainly does exist, albeit in a different database. But my coworker ran a Profiler trace that showed a command being executed looking for //Service/Target on SourceDB. Service broker seems to be getting confused somehow. Adding an explicit route, in addition to being theoretically unnecessary, does not change the situation.

I ran a nearly-identical set of tutorial commands on our test server and everything worked fine, so it is likely something db-specific.

Our setup was working two days ago, so we're probably looking for some setting that might have gotten changed, but with no luck.

来源:https://stackoverflow.com/questions/11658658/troubleshooting-service-broker-initiator-database-stuck-conversing-notified

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!