Hi Nick,
I get very few of them. In the current logs I have three from the last two
days. This is with approx. 300.000 requests per day, so it's actually very
few.
I have a feeling that this suggests that they are caused by external
factors, and that it would then make sense to retry.
Thanks a l
Hi Bek,
Two concurrent transactions on the same entity would not be enough on
its own to cause this exception: If the two conflict, one of them will
get in first, and the other will be failed and automatically retry. It
should take substantially higher contention to cause this. As I
mentioned, th
Hi djidjadji,
Thanks a bunch - I'll try to make the code retry the get()!
Sincerely,
/morten
On Thu, Apr 23, 2009 at 10:35 AM, djidjadji wrote:
>
> You get a Timeout error on a get() operation.
> I solved it by doing a retry when I get an exception.
> If the retry also failed I re-raise the ex
Hi Nick,
Thank you very much for your reply.
The contention is identified in the log:
1.
198.66.245.68 - - [22/Apr/2009:10:19:43 -0700] "GET
/setlocation?ll=40.064929,-75.242851&uid=e5b25e2d512b10fc913c2f8c290f55114550135a&c=28
HTTP/1.1" 500 916 - "gzip(gfe)"
2. E 04-22 10:19AM 43.0
Hi Morten,
The likelihood you'll see a datastore timeout bears a relation to how
expensive your operation is, but external factors - such as transient
issues on our Bigtable Tabletservers - can have a much larger impact.
As such, you'll occasionally (hopefully only very occasionally) see
timeouts
You get a Timeout error on a get() operation.
I solved it by doing a retry when I get an exception.
If the retry also failed I re-raise the exception to get it logged
2009/4/22 Morten Bek Ditlevsen :
>
> Hi there,
> I'm in the process of moving the database part of a social networking
> site to G