Question

I have a Flex application which shows an assessment to a candidate. At the end of the assessment, the asp.NET application sends the session (of the candidate) id to a queue. A Windows Service on another machine handles the queue and performs some jobs.

Now, if for some reason msmq is down, then the session id will not be sent to the queue and an exception will be thrown. I can catch it, but what to do then?

• Store these session ids in a table in database (easy to write some logic that retries sending those messages to the queue)
• Just log an error (hard to retry all failed messages afterwards – would need to read in the log)

!Msmq is not used for service requests from Flex, so the application will keep on running, even if msmq is down.

Answer 1

That’s really a business decision, so YMMV. I tend to advocate this approach:

1) Log everything necessary (including the message body if possible) to resubmit the message later. Store that however. I would go ahead and make it an Exception db so you could also log time of failure, exact exception (in case the problem is that MSMQ is down, but something else blew up) etc.
2) Have some kind of notification system which will notify all parties necessary (business process owner, support, and whoever’s in charge of the MSMQ) of the failure along with enough identifying information to find the logged message in your exception db.