Google App Engine - как вы обрабатываете исключение DatastoreTimeoutException?

Question

Я создал что-то в Google App Engine, который выступает в качестве бэкэнда для iPhone-приложения. В приложении есть взаимодействия, которые вытесняются в социальные сети через их API. Таким образом, типичный рабочий процесс выглядит так:

1. Пользователь использует iPhone приложение, чтобы сделать «что-то»
2. App Engine приложение оповещается через HTTP
3. App Engine оповещает социальной сети, что пользователь сделал «что-то.» Если пользователь должен проверить свой профиль в этой сети, будет отображаться их активность через приложение. Итак, что касается пользователя, то, что они сделали, вероятно, сработало.
4. App Engine должен выполнять некоторую настойчивость самостоятельно, но когда он пытается, генерируется исключение DatastoreTimeException. И теперь данные находятся в состоянии фанки.

Так что же это хороший способ справиться с этим? По своей природе я хотел бы обернуть ее в «транзакцию», но нет способа отбросить то, что было отправлено в Социальную сеть. Итак, я больше думаю о том, как вы обрабатываете DatastoreTimeException? Должен ли я просто обернуть его в блок try и дать ему еще один выход? Лучше ли показывать пользователю ошибку, а затем, когда они снова попытаются «пропустить» взаимодействие в социальной сети, чтобы он не вытолкнул дважды? Есть ли еще одна идея, о которой я не думаю?

Answer 1

http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/datastore/DatastoreTimeoutException.html

«Это может произойти, когда вы пытаетесь поставить, получить или удалить слишком много объектов или объект слишком много свойств, или если хранилищу перегружен или возникли проблемы.»

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

Если вы хотите быть пуленепробиваемым надежными, и вы можете убедиться в том, что операция, которую выполняют в социальной сети является тождественной (можно повторить), то:

• Запишите себе, что вам необходимо выполнить работу в социальной сети.
• Если записка не удалось сохранить, прервать и вернуть отказ.
• В противном случае попытайтесь выполнить операцию в социальной сети.
• В случае успеха удалите примечание.
• Имейте какое-то задание или цикл, чтобы повторить любые оставшиеся записи в будущем.

Конечно, вы должны быть немного осторожным кодом_ответ вы даете клиенту iPhone, так как успех может занять время долго - больше, чем длительность запроса, сделанное приложением iPhone. Поэтому вы хотите, чтобы ваш запрос на движок приложения тоже идемпотент, и вы, вероятно, хотите отменить его.

Если все, что вы получаете из социальной сети, является успешным или неудачным, и в случае успеха операция не должна повторяться, значит, у вас проблемы.Это API-интерфейс для мусора, предлагаемый в Интернете, поскольку только потому, что веб-сервер отправляет вам успешный ответ, это не означает, что вы его получили, поэтому иногда нет возможности для вызывающего абонента знать, что они преуспели, даже если успех создает обязанности , Но это происходит.

Answer 2

Я нахожу это заявление тревожным: На практике повторная попытка часто бывает успешной; вы будете периодически получать тайм-ауты хранилища данных даже для небольших операций. - Wooble 23 января в 14:59

Как можно серьезно относиться к GAE, если у него есть проблемы с надежностью? Как правило, вы находите хранилище данных медленным? Какова ваша оценка частоты этих исключений?

Answer 3

Это фундаментальная проблема с любой распределенной системой. В общем, нет простого «пуленепробиваемого» решения. Лучший вариант, если это возможно, состоит в том, чтобы убедиться, что одна или обе ваши операции идемпотентны, то есть выполнение их несколько раз не имеет никакого эффекта. Для хранилища данных это довольно просто: если вы укажете имя ключа, несколько puts просто перезапишут друг друга. Если это возможно, вы также должны использовать идемпотентность в своем социальном API, чтобы вы могли безопасно выполнить повторный запуск в случае сбоя.