What to do if Msmq is down and your asp.NET application relies on it?

I have a Flex application which shows an assessment to a candidate. At the end of the assessment, the asp.NET a开发者_JAVA百科pplication 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.

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.

Store all session IDs in a table in the database, and have your Windows Service on the other machine read the IDs from this table (bypassing the message queue entirely).

So the Flex is hosted on the client in a web page? Therefore is it communicating back to a server, which in turn is posting the message to the queue. Or is flex posting to the q directly using HTTP. If it is the later (flex communicating directly to the q) then there's not a lot you can do if the q is down.

If flex is talking to the server which communicates to the q, you've got a couple of options. You could do exactly what you say, but then you'd need a separate process to read the offline data storage and handle the posting of messages once the q became available. If the q is hosted on another server to the service, you could set up a local q (which should always be available and then have that replicate to the remove q as and when it's available (so the msmq technology handles the network down time, etc).

Or you could bypass the queue completely as per '@MusiGenesis' answer if it's not actually needed.