Google App Engine - как вы обрабатываете исключение DatastoreTimeoutException? - PullRequest
0 голосов
/ 23 января 2010

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

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

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

Ответы [ 3 ]

1 голос
/ 23 января 2010

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

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

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

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

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

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

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

0 голосов
/ 28 января 2010

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

0 голосов
/ 26 января 2010

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

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

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