问题
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 setTRUSTWORTHY
is set- Have a unique
service_broker_guid
- Have
sa
as db owner, with all SSB authorization statements aredbo
orOWNER
, 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 inCONVERSING
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 inCONVERSING
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