Hi Gayle,
Could you email your app id (x.appspot.com) ? I'd be happy to look
into this for you.
Cheers,
Jeff
On Nov 13, 12:43 pm, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
> I'm now hitting TONS of "over quota" errors, and I wasn't before.
>
> This is really hurting my revenue today.
>
> http:
I'm now hitting TONS of "over quota" errors, and I wasn't before.
This is really hurting my revenue today.
http://www.careercup.com
On Nov 13, 11:09 am, "Brett (Google)" <[EMAIL PROTECTED]>
wrote:
> Hi Gee,
>
> Definitely understood that there's been quite a bit of trouble the
> last two days,
Hi Gee,
Definitely understood that there's been quite a bit of trouble the
last two days, especially for you and a few other apps. We're sorry
you guys have been hurting from this. I can imagine it's especially
frustrating for a growing service.
In the specific case of this memcache maintenance,
Hi Gee,
Can you please reply to me with your app ID and I can look in to it.
-Marzia
On Thu, Nov 13, 2008 at 10:50 AM, gee <[EMAIL PROTECTED]> wrote:
>
>
> Hi Brett,
>
> During this time, it would have been very extremely helpful if CPU/
> response time quotas were relaxed.
>
> All our cache mi
Hi Brett,
During this time, it would have been very extremely helpful if CPU/
response time quotas were relaxed.
All our cache misses are adding up, and we're now over quota.
We've had significant downtime over the last two days due to the
scheduled downtimes going awry (our app was one of tho
Memcache calls should now be failing fast. That should significantly
reduce the number of request deadlines people are seeing. Otherwise,
we're working to bring the memcache API back online for all
applications as soon as possible. Thanks again for your patience,
everyone!
On Nov 13, 10:12 am, "B
Hi Gayle,
Yes, the *request* times out during the API call. It's not the API
call itself that's timing out. But there is no effective difference to
your application if you're caught in this situation (as you pointed
out). I'd assume the first few calls you make to memcache during a
request actual
It was timing out within memcache.get and memcache.set -
consistently. If I understand you correctly - you're saying that
memcache isn't technically timing out, on the grounds that it would
complete if given enough time. But, the cache misses take SO much
time that it consistently timeouts durin
I second Gayle's points entirely.
We're getting hit with a huge number of deadline exceeded errors at
the moment, all due more or less to cache misses.
Site is basically unusable for our users.
Gee
On Nov 13, 9:29 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
> Despite what the post at the
They're timing out for me as well
App-ID - lifesizedpicx
:
Traceback (most recent call last):
File "/base/data/home/apps/lifesizedpicx/4.26/home.py", line 1316,
in main
run_wsgi_app (application)
File "/base/python_lib/versions/1/google/appengine/ext/webapp/
util.py", line 76, in run_wsg
Hi Gayle,
I'm sorry to hear you're seeing issues. It's important to note that
there are two types of DeadlineExceededErrors. One is defined in
apiproxy_errors.py. The other is in runtime/__init__.py:
http://code.google.com/p/googleappengine/source/browse/trunk/google/appengine/runtime/__init__.p
Pete,
Please also check this post:
http://groups.google.com/group/google-appengine/browse_thread/thread/d8a3a54df62e1b04
I guess, you've messed something up with versions.
Denis
--~--~-~--~~~---~--~~
You received this message because you are subscribed to th
Hi Gayle,
Would you mind sending either your app_id or a stack trace to
[EMAIL PROTECTED] We haven't seen this globally and would like to
look into it.
Thanks!
Pete, App Engine Team
On Nov 13, 9:29 am, Gayle Laakmann <[EMAIL PROTECTED]> wrote:
> Despite what the post at the link below says, me
13 matches
Mail list logo
