> --
> You received this message because you are subscribed to the Google Groups "Google App Engine" group.
> To post to this group, send email to google-a...@googlegroups.com.
> To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
>
>
--
Takashi Matsuo
matsuo....@gmail.com
Kay's daddy
2010/7/1 Luís Marques <luism...@gmail.com>:
> Same here, in the spam folder marked as fishing.
>
> Luís
>
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
It would be nice if AppEngine would post a message to our apps before
it enters maintenance mode and again when it resumes to normal
operation mode. This would allow us to disable features that require
writing to the datastore. I realize we can catch the capability
exceptions but that means we need to try to write first, which is not
good enough IMO.
Regards,
Viðar
> --
> You received this message because you are subscribed to the Google Groups "Google App Engine" group.
> To post to this group, send email to google-a...@googlegroups.com.
> To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
But like you said, there are other ways to check this during a r-o
mode and a quick memcache put might be the best way. I haven't
research what is the optimal approach here.
Regardless, that does not help us if we need to perform some work
before entering r-o mode.
Let's say that the notification is sent one hour in advance. Then we
might want to:
* Prioritize critical background processing work so it completes
before the deadline.
* Disable non-essential work to minimize overall workload when the app
enters r-o mode.
* Notify our users that our app will soon enter a r-o state and that
features will be disabled.
* Notify developers that missed the email for some reason (gmail
marked it as spam, etc).
* If the app is a service, notify other apps that it is to go offline.
Of course, it would also help if the notification included an
estimation of the downtime.
Given the frequent downtimes, it is essential that there is a way to
handle them more gracefully than the current approach allows. At least
if we want to build non-toy apps.
- Viðar