3 ms·
The biggest limitation I had was while writing to the database, the database would sometimes return an error for no apparent reason. I'd then be forced to catc
by rubypay 16y ago
The biggest limitation I had was while writing to the database, the database would sometimes return an error for no apparent reason. I'd then be forced to catch these errors, and resubmit. But if you had lots of traffic and resubmit too quickly, Google App Engine would throw more errors back at you. This was all over a year ago, not sure how it is now, I would never go back to using it.
From http://code.google.com/appengine/articles/life_of_write.html http://code.google.com/appengine/articles/life_of_write.html
There is an expected failure rate on writes as Bigtable tablets are sometimes unavailable, for example, when they are being moved or split. The presence of more indexes increases the probability of hitting an unavailable tablet as an exception will be raised if a write fails for any of the indexes.
In those situations, your application will need to decide how to handle the exception. One option is to add a task to the task queue to retry the write at a later point in time. Another idea would be to respond with an error from the app and have the client retry. This tends to work with things like AJAX requests where there is client side logic which can handle an error message from the server.
- follower 16y agoThis might have been reduced by the release in February: http://googleappengine.blogspot.com/2010/02/app-engine-sdk-131-including-major.html http://googleappengine.blogspot.com/2010/02/app-engine-sdk-1... See the section "Reduced error rate with Automatic Datastore Retries". I haven't kept a close watch on what's changed since then though.
- nl 16y agoThat helped some, but there was a release (to the backend infrastructure, not the AppEngine SDK) about a month ago that made a huge difference. Edit: Here's the link that shows the improvement: http://code.google.com/status/appengine/detail/datastore/2010/11/06#ae-trust-detail-datastore-get-latency http://code.google.com/status/appengine/detail/datastore/201...
- fharper1961 16y agoYes that day looks impressive, but if you look at the following days, the improvement does not look anywhere near as dramatic. http://code.google.com/status/appengine/detail/datastore/2010/11/18#ae-trust-detail-datastore-get-latency http://code.google.com/status/appengine/detail/datastore/201...
- gojomo 16y agoWeird. If the entire keyspace isn't affected, seems like you might want to use another region as the 'task queue'. That is, if you get an error where you want to insert something, add a prefix that lands it on another tablet. Occasionally scan those failover regions for values that can be moved back to their real keys, later.
- nikcub 16y agocheckout the following issues: http://code.google.com/p/googleappengine/issues/detail?id=1758&q=model%20exception&colspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Summary%20Log%20Component%20Language http://code.google.com/p/googleappengine/issues/detail?id=17... http://code.google.com/p/googleappengine/issues/detail?id=1409 http://code.google.com/p/googleappengine/issues/detail?id=14... you need to trap DeadlineExceededError for long-running queries, CapabilityDisabledError (from google.appengine.runtime.apiproxy_errors) for when the datastore is in maintenance mode and other misc errors. If it is a deadline error, you can re-submit it (but prob advisable to only re-sub once), on CapabilityDisabledError, return a server error page or load from memcache