質問

In sys.transmission_queue the only information I'm given is "One or more messages could not be delivered to the local service targeted by this dialog."

If I re-enable one of the problem queues (there are five) and leave Activation set to OFF, the queue fills up with its messages. If I then run the Activation SP, I process the messages correctly and without issue. But as soon as I turn activation ON, if there are ANY messages in the queue, the queues will disable themselves again.

I'm completely lost. Does anyone know how I can troubleshoot this?

役に立ちましたか?

解決

The queues disable themselves as a reaction to poison message handling protection. It means that your activated procedure is rolling back, probably due to some exception. Activated procedure do not have a session to send errors to, so they send it to ERRORLOG instead. Check your errorlog, should be riddled with error messages from your activated procedures.

The easiest way to troubleshoot is to simply run the activated procedure manually, from SSMS, when the activation is OFF. Try to recreate the same execution context as activation, see Internal Activation Context. The critical part is the EXECUTE AS context which is changing a lot of behavior, especially security. So try this (assuming your queue executes under dbo):

use <dbname>;
go

execute as user = 'dbo';
go

exec <sp_my_activated_proc>;
go

revert;
go

You will likely get an error message which is probably the cause of your repeated disables.

他のヒント

I would assume I'm getting this poison message handling.

The queue disables after the first message Happening in 2008 and 2012. But worked fine on my dev PC with 2008 r2

However, nothing shows up in the "SQL Server Logs"

If I create the queue without the activation clause and run the SQL manually, then the SP runs and returns without an error (nothing in the log again either), and the queue disables

If I manage to figure out the cause I'll update this.

It was message poisoning - silent failure after 5 rollbacks in a row.

Never did find any logs, but the cause was the NULL check I had:

WAITFOR
(
    RECEIVE TOP(1)
        @msg        = convert(xml,message_body),
        @DlgId      = conversation_handle
    FROM dbo.AuditLog_Request_Queue
), TIMEOUT 1000;

-- exit when waiting has been timed out
IF @@ROWCOUNT = 0
BEGIN
    IF @@TRANCOUNT > 0
    BEGIN
        ROLLBACK TRANSACTION;
    END
    BREAK;
END

-- exit when waiting has been timed out
IF @msg IS NULL
BEGIN
    IF @@TRANCOUNT > 0
    BEGIN
        ROLLBACK TRANSACTION;
    END
    BREAK;
END

Moving that to around the later EXECUTE statement stopped the problem

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top