title: Queue stops (disables) without any poison message
body: <p>I have a queue that stops without any aparently reason, in this queue i have implemented a <b>posion message handling</b>. And during processing, it records and discards any poison messages.</p>
  
  <p>It has worked fine for more than a year without stopping. But recently (the problem began four weeks ago), it stops once or twice a week. And only in this week it stopped twice.</p>
  
  <p>And when I check the table with the new poisoned messages, there is none!! And when I enable the queue, processing resumes successfully and the 'poison message' situation does not reproduce.</p>
  
  <p>About the task of the queue: Receives about 2-3000 messages per day. It is used to run stored procedures outside the transaction. And each message can last a little to be processed (doing a lot of selects, inserts, updates).</p>
  
  <p>Let me explain this point: the database has triggers that are fired inside a transaction, the trigger sends a message to run some code outside the trigger. The asynchronous behavior prevents droping the performance of the database.</p>
  
  <p>I have detected that even when a dead-lock occurs while proccessing the messages, the queue treats the message as poisoned. So in principle it shouldn't be a performance problem. But, can it be? Maybe the database is growing and it lasts too long to proces a messages?</p>
  
  <p>But how can I find it out if it is not detected as posioned?<br/>
  Why other reason a queue stops?<br/>
  How can save when and with which message the queue got disabled?<br/>
  Does anybody has any idea how I can do any forensics analysis?<br/>
  Any idea?</p>
  
  <p><hr />
  <b>UPDATE EXPOSING A PSEUDO-SOLUTION:</b><br/>
  According Remus' post, I've tried to use the event notification to get the exact moment when the queue stops.</p>
  
  <pre><code>CREATE EVENT NOTIFICATION [QueueDisabledEN]
    ON QUEUE [dbo].[ProcessQueue]
    FOR BROKER_QUEUE_DISABLED
    TO SERVICE 'Queue Watch Service', 'current database';
  </code></pre>
  
  <p>And then checking the event log:</p>
  
  <pre><code>select * from sys.event_notificiation
  </code></pre>
  
  <p>But since it is difficult to know the environment in which the event occurred, (what else was running at the momment??), forensic analysis ends there. Fortunately my broker service implementation stores the messages with the date of shipment, the date of receipt, date processing, ... This has helped me to detect that within 3 seconds the queue is flooded with hundreds of messages that take too long to be processed.</p>
  
  <p>While I find a real solution the only temporary solution is to check with an agent job every x minutes the status of the queue and enable it:</p>
  
  <pre><code>IF (EXISTS(SELECT * FROM sys.service_queues WHERE name like 'ProcessQueue' AND (is_receive_enabled = 0 OR is_enqueue_enabled = 0))) BEGIN
      PRINT convert(nvarchar, getdate(), 121)+ ': Activando la cola ProcessQueue'
      ALTER QUEUE ProcessQueue WITH STATUS = ON 
  END
  </code></pre>
  
  <p>Thanks Remus!</p>