Windows Azure staging <--> production, вызывающая конфликты и ошибки в хранилище таблиц

У нас вчера была ужасная проблема / опыт, когда мы пытались поменять местами нашу промежуточную <--> производственную роль.

Вот наша установка:

У нас есть рабочая роль, собирающая сообщения из очереди. Эти сообщения обрабатываются ролью. (Вставки для хранения таблиц, выбор БД и т. Д.). Это может занять 1-3 секунды на сообщение очереди в зависимости от того, сколько сообщений в хранилище таблиц ему нужно сделать. Он удалит сообщение, когда все будет готово.

Проблема при обмене местами:

Когда наш промежуточный проект был запущен в оперативный режим, наша рабочая роль начала выдавать ошибку.

Когда роль хотела обработать сообщения очереди, она выдавала постоянный поток ошибок « EntityAlreadyExists ». Из-за этих ошибок сообщения очереди не удалялись. Это заставляло сообщения очереди помещаться обратно в очередь и снова обрабатываться, и так далее ....

При просмотре этих сообщений очереди и анализе того, что с ними произойдет, мы увидели, что они действительно были обработаны, но не удалены.

Проблема не исчезла при удалении этих ошибочных сообщений. Новые сообщения в очереди также не обрабатывались, поскольку они еще не обрабатывались и не добавлялись записи хранилища таблиц, что звучит очень странно.

При удалении промежуточного и производственного этапов и повторной публикации в продакшн все стало работать нормально.

Возможные проблемы?

Мы мало 2 понятия не имеем, что произошло на самом деле.

• Может быть, обе роли получили одни и те же сообщения, и одна написала сообщение, а другая - с ошибкой?
• ... ???

Возможное (ые) решение (я)?

У нас есть некоторые идеи, как решить Эта проблема'.

• Сделать аварийное сообщение для отработки отказа системы? Когда счетчик удаления из очереди превышает X, мы должны просто удалить это сообщение из очереди или поместить его в отдельную «опасную очередь».
• Перехватите ошибку EntityAlreadyExists и просто удалите это сообщение из очереди или поместите его в отдельную очередь.
• ... ????

Несколько ролей

Полагаю, у нас возникнет такая же проблема при назначении нескольких ролей?

Большое спасибо.

РЕДАКТИРОВАТЬ 24/02/2012 - Дополнительная информация

• Фактически мы используем GetMessage ()
• Каждый элемент в очереди уникален и будет генерировать уникальные сообщения в таблице Storage. Немного дополнительной информации о процессе: пользователь что-то публикует, и его нужно будет распространить среди других пользователей. Сообщение, сгенерированное этим пользователем, будет иметь уникальный идентификатор (guid). Это сообщение будет помещено в очередь и получено рабочей ролью. Сообщение распределяется по нескольким другим таблицам (ключ раздела -> UserId, rowkey -> Временная метка в тиках и уникальный идентификатор сообщения. Таким образом, почти нет шансов, что те же сообщения будут отправлены в нормальной ситуации.
• Время невидимости out МОЖЕТ быть логическим объяснением , потому что некоторые сообщения могут быть распределены по 10-20 таблицам, что означает вставку 10-20 без пакетной опции.Можете ли вы установить или расширить это время невидимости ?
• Невозможность удаления сообщения из очереди из-за исключения МОЖЕТ также быть объяснением, потому что мы не реализовали ни одно подозрительное сообщение. по ЕЩЁ;).