Что делать, если Msmq не работает и ваше приложение asp.NET полагается на него?

Question

У меня есть приложение Flex, которое показывает оценку кандидата. В конце оценки приложение asp.NET отправляет идентификатор сеанса (кандидата) в очередь. Служба Windows на другом компьютере обрабатывает очередь и выполняет некоторые задания.

Теперь, если по какой-то причине msmq не работает, идентификатор сеанса не будет отправлен в очередь и будет сгенерировано исключение. Я могу поймать это, но что делать тогда?

• Сохранение этих идентификаторов сеансов в таблице в базе данных (легко написать некоторую логику, которая повторяет отправку этих сообщений в очередь)
• Просто зарегистрируйте ошибку (трудно повторить все сообщения о сбоях - нужно будет прочитать в журнале)

! Msmq не используется для запросов на обслуживание от Flex, поэтому приложение будет продолжать работать, даже если msmq не работает.

Answer 1

Сохраните все идентификаторы сеанса в таблице в базе данных, и ваша служба Windows на другом компьютере будет считывать идентификаторы из этой таблицы (полностью обходя очередь сообщений).

Answer 2

То есть Flex размещается на клиенте на веб-странице? Поэтому он связывается с сервером, который, в свою очередь, отправляет сообщение в очередь. Или гибкая публикация в q напрямую через HTTP. Если это позднее (гибкое общение напрямую с q), то вы не сможете многое сделать, если q не работает.

Если flex разговаривает с сервером, который общается с q, у вас есть несколько вариантов. Вы можете делать именно то, что говорите, но тогда вам понадобится отдельный процесс для чтения автономного хранилища данных и обработки отправки сообщений, как только станет доступным q. Если q размещен на другом сервере службы, вы можете установить локальный q (который должен быть всегда доступен, а затем иметь его копию для удаления q, как и когда он будет доступен (поэтому технология msmq обрабатывает время простоя сети, и т.д.).

Или вы можете полностью обойти очередь согласно ответу '@MusiGenesis', если он на самом деле не нужен.

Answer 3

Это действительно деловое решение, так что YMMV. Я склонен защищать этот подход:

1) Зарегистрируйте все необходимое (включая тело сообщения, если это возможно), чтобы повторно отправить сообщение позже. Сохраните это однако. Я хотел бы сделать это и сделать его исключительной БД, чтобы вы могли также регистрировать время сбоя, точное исключение (в случае, если проблема в том, что MSMQ не работает, но что-то еще взорвалось) и т. Д.
2) Иметь какую-то систему уведомлений, которая будет уведомлять все необходимые стороны (владельца бизнес-процесса, техподдержки и тех, кто отвечает за MSMQ) о сбое, а также достаточно идентификационной информации, чтобы найти зарегистрированное сообщение в вашем исключительном случае.