Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
DB Engine
SQL ServerMSDESQL Server CE
Services
Analysis (Data Mining)Analysis (OLAP)DTSIntegration ServicesNotification ServicesReporting Services
Programming
CLRConnectivitySQLXML
Other Technologies
ClusteringEnglish QueryFull-Text SearchReplicationService Broker
General
Data WarehousingPerformanceSecuritySetupSQL Server ToolsOther SQL Server Topics
DirectoryUser Groups
Related Topics
MS AccessOther DB ProductsMS Server Products.NET DevelopmentVB DevelopmentJava DevelopmentMore Topics ...

SQL Server Forum / Other Technologies / Service Broker / December 2006

Tip: Looking for answers? Try searching our database.

Activation procedure causes queue to be disabled, but manually running SP works OK

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Laurence Neville - 21 Dec 2006 11:26 GMT
If I enable activation on my queue, as soon as a message arrives the queue
becomes disabled. I understand that this is usually due to an error
occurring in the activation SP. However, if I disable activation, let a
message arrive and then run the same SP manually using the same SQL login as
the queue uses, the SP completes successfully, the message is removed from
the queue and the queue is not disabled. What could be going on????

Here is the code of the SP:

create proc EurProcessNewReceiptMessages
as
begin -- SP

set nocount on
set xact_abort on

declare @MessageType sysname
declare @ConversationHandle uniqueidentifier
declare @MessageBody xml
declare @ErrorMessage varchar(8000)
declare @ReceiptID int
declare @TimeYearID int, @WeekNo int

--  This procedure will just sit in a loop processing messages from the
queue
--  until the queue is empty
while (1 = 1)
begin -- Check for new messages to process
begin transaction
 -- Receive the next available message
 waitfor (
  receive top(1) -- just handle one message at a time
  @MessageType = message_type_name,  --the type of message received
  @MessageBody = message_body,      -- the message contents
  @ConversationHandle = conversation_handle    -- the identifier of the
dialog this message was received on
  from RMIS_COMMS_Queue
 ), timeout 5000  -- if the queue is empty for five seconds, give up and go
away

 -- If we didn't get anything, the queue is empty so bail out
 if (@@rowcount = 0)
 begin -- No new message to process
  --rollback transaction
  commit transaction
  break
 end -- No new message to process
 else
 begin -- New message to process
  if (@MessageType =
'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog')
  begin -- Message is an End Dialog
   end conversation @ConversationHandle
  end -- Message is an End Dialog
  else if (@MessageType =
'http://schemas.microsoft.com/SQL/ServiceBroker/Error')
  begin -- Message is an Error
   set @ErrorMessage = 'A message with type: ' + convert(varchar(8000),
@MessageType) + ' was found in Service Broker conversation: ' +
convert(varchar(8000), @ConversationHandle) + ' at: ' + convert(varchar(25),
getdate(), 101) + char(13)
   set @ErrorMessage = @ErrorMessage + 'Message contents: ' + char(13) +
convert(varchar(8000), @MessageBody)
   raiserror (@ErrorMessage , 19, 1) with log

   end conversation @ConversationHandle
  end -- Message is an Error
  else if (@MessageType = 'RMIS_Sales_Msg')
  begin -- Message is a receipt

   -- Check the incoming receipt number is not already in the database
   if not exists (select ph.* from pm_trans_header ph join
@MessageBody.nodes('/PMH') receipt(header) on ph.branch_id =
receipt.header.value('@BranchID', 'int') and ph.till_no =
receipt.header.value('@TillNo', 'int') and ph.receipt_no =
receipt.header.value('@ReceiptNo', 'varchar(15)'))
   begin -- Message is a new receipt

    select @TimeYearID = time_year_id, @WeekNo = current_week
    from global_param (nolock)
   -- LOTS OF CODE (THAT PROCESSES THE MESSAGE DATA) REMOVED HERE
   end -- Message is a new receipt
  end -- Message is a receipt

  commit transaction
 end -- New message to process
end -- Check for new messages to process
end -- SP
go

grant execute on EurProcessNewReceiptMessages to remcert
go

Here is a trace run on the server:

Broker:Connection          19 2006-12-21 11:01:57.857
Audit Broker Login          19 2006-12-21 11:01:59.280
Broker:Message Classify           19 2006-12-21 11:01:59.403
Broker:Conversation Group          19 2006-12-21 11:01:59.420
Broker:Conversation STARTED_INBOUND         19 2006-12-21 11:01:59.420
Broker:Conversation CONVERSING         19 2006-12-21 11:01:59.420
Broker:Remote Message Acknowledgement          19 2006-12-21 11:01:59.420
Broker:Conversation DISCONNECTED_INBOUND         19 2006-12-21 11:01:59.420
Broker:Remote Message Acknowledgement          19 2006-12-21 11:01:59.420
Broker:Activation          19 2006-12-21 11:01:59.420
Broker:Message Classify           20 2006-12-21 11:01:59.420
Broker:Remote Message Acknowledgement          18 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Activation          60 2006-12-21 11:01:59.420
Broker:Queue Disabled          20 2006-12-21 11:01:59.420
SQL:StmtRecompile waitfor (
  receive top(1) -- just handle one message at a time
  @MessageType = message_type_name,  --the type of message received
  @MessageBody = message_body,      -- the message contents
  @ConversationHandle = conversation_handle    -- the identifier of the
dialog this message was received on
  from RMIS_COMMS_Queue
 ), timeout 5000  -- if the queue is empty for five seconds, give up and go
away

 -- If we didn't get anything, the queue is empty so bail out
Laurence Neville - 21 Dec 2006 11:37 GMT
Just to clarify - where it says in the SP:
-- LOTS OF CODE (THAT PROCESSES THE MESSAGE DATA) REMOVED HERE

... this exact code for the SP still causes the queue to be disabled (i.e.
it is being disabled even with all the code that processes the message data
removed).

> If I enable activation on my queue, as soon as a message arrives the queue
> becomes disabled. I understand that this is usually due to an error
[quoted text clipped - 130 lines]
>
>  -- If we didn't get anything, the queue is empty so bail out
Remus Rusanu [MSFT] - 21 Dec 2006 15:51 GMT
Is there anything traced in the errorlog or the system even viewer?

Run the SP manually after first issuing an EXECUTE AS:

EXECUTE AS USER = 'activated_execute_as_user';
EXEC <activatedproc>;
REVERT;

There are big differences between the login context and the execute as
context. Also see these blog entries:
http://blogs.msdn.com/remusrusanu/archive/2006/01/12/512085.aspx
http://blogs.msdn.com/remusrusanu/archive/2006/03/07/545508.aspx
http://blogs.msdn.com/remusrusanu/archive/2006/03/01/541882.aspx

HTH,
~ Remus

> If I enable activation on my queue, as soon as a message arrives the queue
> becomes disabled. I understand that this is usually due to an error
[quoted text clipped - 130 lines]
>
>  -- If we didn't get anything, the queue is empty so bail out
Laurence Neville - 21 Dec 2006 17:47 GMT
I figured it out. I need to set arithabort on within the SP. If arithabort
is off when the SP is run then any use of XQuery seems to fail. I guess when
I ran the SP manually in Query Analyzer arithabort was on, but when it ran
as an activation procedure it was off.

> Is there anything traced in the errorlog or the system even viewer?
>
[quoted text clipped - 147 lines]
>>
>>  -- If we didn't get anything, the queue is empty so bail out
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.