On Thu, Jun 14, 2012 at 5:01 PM, Jeff Schnitzer j...@infohazard.org wrote:
On Thu, Jun 14, 2012 at 9:54 AM, Jon McAlister jon...@google.com wrote:
Jeff Schnitzer:
} Degraded service == more profitable is a perverse
} incentive, and will eventually produce undesirable development
} priorities
I'm an engineer on the App Engine team, and work as the TL for
the scheduler, appserver, and other serving infrastructure. I am
also closely involved with production and reliability issues. I
can offer some perspective here.
Jeff Schnitzer:
} Degraded service == more profitable is a perverse
}
For python25, the change for cpu and memory is immediate. For java,
the change for cpu is immediate but not memory. For python27, the
change for memory is immediate but not cpu. For the cases where the
change is not immediate, I mean that the change does not apply until
new instances are turned
See
http://groups.google.com/group/google-appengine/browse_thread/thread/edbfdc06bffcfab1
On Thu, Dec 15, 2011 at 6:13 AM, mike hershey mikehershe...@gmail.com wrote:
I've been watching my app and it typically idles at 80mb, and slowly uses
more and more memory until it is just over 256 ram.
Yes, F1 is what all frontend instances were using prior to the 1.6.1 release.
Scott, the issue with your instances dashboard is that our accounting
and enforcement of java memory is different than for python, and this
implementation detail is bleeding through the interface here.
Specifically,
Sorry, that number 10% was chosen arbitrarily and not based on hard
data. The point was just that there is overhead but that is not
something we are charging for. The instance class size for java
determines the jvm heap size.
On Wed, Dec 14, 2011 at 10:31 AM, Jon McAlister jon...@google.com wrote
I took a look. Not yet sure what the cause was, but perhaps these data
will help you.
First thing was to zoom-in on the relationship between latency and
instances. Attached is the graph. You can see there that first
latencies shoot up, and then subsequently the scheduler is adding
instances, and
instead of 400
On Dec 7, 6:39 pm, Jon McAlister jon...@google.com wrote:
I took a look. Not yet sure what the cause was, but perhaps these data
will help you.
First thing was to zoom-in on the relationship between latency and
instances. Attached is the graph. You can see there that first
Added response here:
http://code.google.com/p/googleappengine/issues/detail?id=6395
On Tue, Nov 22, 2011 at 9:27 AM, Ganesh Subramanian gsu...@gmail.com wrote:
PURCELLMARIANORG FRONTEND INSTANCE HOURS DESCREPENCY FOR NOV 20 2011
PURCELLMARIANORG SHOULD BE CHARGED 0.07 cents for Nov 20 not
Are there other reasons holding you back? I ask because the two you
have listed could both be overcome. The simplest design I could
imagine would be for you to code your own authorization and accounting
system within your app. It would take some work, but would presumably
pay for itself in terms
To clarify, the billed instances graph (i.e. the green line) will only be
present on the default version for your app. This is because of many
subtleties (e.g. the formula is per-app not per-version, the admin-console
only renders graphs per version), but as long as the default version serves
the duration of the previously attached graph :)
On Sep 12, 10:36 am, Jon McAlister jon...@google.com wrote:
Nevermind, I remember, it's everpix-alpha.
I see that min-idle-instances was removed on 2011/08/31-19:49:59 and
then set to 3 on 2011/09/11-09:47:38. So, it wasn't on when you emailed
Yep, Tim is right. Thanks again Tim for reformulating the logic and
making it easy to understand.
} Now I don't know what would happen if max-idle-instances was set
} to automatic, whether this means 1 (no you wouldn't be
} billed), infinity (yes you'd be billed for all 100),
Right now it's the
What's the app-id?
On Sun, Sep 11, 2011 at 9:53 AM, Pol-Online i...@pol-online.net wrote:
Hi,
Because we are about to launch our app very soon, I increased the number of
idle instances from 1 to 5 yesterday and things looked correct in the
Dashboard.
Then this morning, in the Dashboard I
Backends are one good way to do this. You can direct tasks at a
backend, and then control the number of instances for that backend
directly. http://code.google.com/appengine/docs/python/backends/overview.html
Once the billing rollout is complete, the treatment of tasks and
non-task requests,
Nevermind, I remember, it's everpix-alpha.
I see that min-idle-instances was removed on 2011/08/31-19:49:59 and
then set to 3 on 2011/09/11-09:47:38. So, it wasn't on when you emailed but
is on now. Your instances graph now looks correct.
On Mon, Sep 12, 2011 at 10:24 AM, Jon McAlister jon
0 0:32:12 24.6 MBytes Dynamic
0.000 0.0 ms 3 0 0:32:09 14.5 MBytes Dynamic
On Sep 9, 1:43 pm, Jon McAlister jon...@google.com wrote:
Ok, let me know if it recurs.
On Wed, Sep 7, 2011 at 3:07 PM, Pol i...@pol-online.net wrote:
Hi Jon,
Great
http://code.google.com/appengine/docs/python/backends/overview.html#Logging
On Mon, Sep 12, 2011 at 12:28 PM, pdknsk pdk...@googlemail.com wrote:
I've noticed that log messages are only logged with the request if
logging() is not used more than twice. Otherwise I have to select
'Info' in the
Sounds reasonable to me. Perhaps file an issue for this?
On Mon, Sep 12, 2011 at 12:39 PM, pdknsk pdk...@googlemail.com wrote:
I understand this, but why the difference? I very much prefer to not
have to switch the filter with 2 messages.
--
You received this message because you are
(1) is correct. (2) is wrong because it is assuming things are the
same all day long which is not true in your example, in your example,
there are three kinds of minutes, the [0:5] range, the [5:20] range,
and the [20:60] range. The three ranges need to be computed
independently (as the billing
Correct, resident instances (those from always-on or
min-idle-instances) are billed differently than dynamic instances. A
resident instance is always assumed to be active, although it does not
show up on the active-instances-graph, which is confusing.
On Wed, Sep 7, 2011 at 4:08 AM, John
. I strongly
advise you to sign up for the Python 2.7 trusted tester program:
http://groups.google.com/group/google-appengine-python/browse_thread/thread/4bde29d8e6dc0842?pli=1,
as that will make the biggest impact for you.
I hope that helps,
Jon
On Fri, Sep 9, 2011 at 10:04 AM, Jon McAlister jon
: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Jon McAlister
Sent: Friday, September 09, 2011 12:12 PM
To: google-appengine@googlegroups.com
Subject: Re: [google-appengine] If the Scheduler worked right (and it
doesn't)...
Hi Brandon,
I've put
Ok, let me know if it recurs.
On Wed, Sep 7, 2011 at 3:07 PM, Pol i...@pol-online.net wrote:
Hi Jon,
Great!
everpix-alpha
I still see what appears to be the bug now and then, but I don't have
a reproducible case just waiting in a task queue anymore.
On Sep 7, 1:19 pm, Jon McAlister jon
The app is relatively quick. The cause of the instance hours is that
the app has a cron job which runs once every two minutes. It returns
quickly, but it keeps the instance pegged all day long. So, low-cpu
but high instance-usage.
On Fri, Sep 9, 2011 at 2:40 PM, Steve Sherrie
On Thu, Sep 8, 2011 at 6:56 AM, Joshua Smith joshuaesm...@charter.net wrote:
I take issue with this:
On Sep 8, 2011, at 6:07 AM, Tim wrote:
- An instance starts when either
- it is needed to serve a request (there are no IDLE or FREE-IDLE
instances available subject to
:45 AM, Joshua Smith joshuaesm...@charter.netwrote:
On Sep 8, 2011, at 10:36 AM, Jon McAlister wrote:
I thought I did respond... In any event, for the reasons you listed
above and others, this is why max-idle-instances is important. It
ensures that you are not held accountable for scheduler
On Thu, Sep 8, 2011 at 10:37 AM, Jon McAlister jon...@google.com wrote:
Hi Joshua,
You are right, I should have been more explicit. While I believe
what I said to be true for most apps, you are right that there
exists classes of apps where the second half of the billing
formula needs
On Thu, Sep 8, 2011 at 11:01 AM, Joshua Smith joshuaesm...@charter.net wrote:
That all sounds right to me. And note that I'm not really worried about this
because:
1) I have to give you $9 anyway, and
2) When 2.7 comes out, assuming I survive the switch to HR, I should be able
to handle
:
On Sep 8, 2011, at 2:17 PM, Jon McAlister wrote:
I would not
characterize this example as heavy-handed
Nor would I. I was thinking more of that poor fellow who's seeing a 100
instance spike every two hours. That's scary.
-Joshua
--
You received this message because you are subscribed
Hi Tim,
On Wed, Sep 7, 2011 at 2:07 AM, Tim meer...@gmail.com wrote:
Jon,
Thanks for that explanation, but if it's authoritative (not meaning to sound
rude, but I hope .. I take it you're on the AppEngine team rather than a
user explaining your understanding of how pricing applies) then it
On Wed, Sep 7, 2011 at 7:20 AM, Tammo Freese i...@flockofbirds.net wrote:
Hi Jon,
On Sep 6, 6:49 pm, Jon McAlister jon...@google.com wrote:
} there is a startup fee of 15 minutes for each instance.
This only affects the computation of the total-instances variable
in the formula, it does
On Wed, Sep 7, 2011 at 9:02 AM, Tim meer...@gmail.com wrote:
On Wednesday, 7 September 2011 15:46:21 UTC+1, Jon McAlister wrote:
Understood. And again, apologies. We mean well, we messed up, we're
working on it.
An authoritative explanation of the intent (there's that word again
Greg
an
email off-list.
On Sep 7, 4:49 pm, Jon McAlister jon...@google.com wrote:
On Wed, Sep 7, 2011 at 7:20 AM, Tammo Freese i...@flockofbirds.net wrote:
so total-instances is the maximum of active-instances over the last 15
minutes?
Not really, no.
So what is total-instances then? I know
Hi Per,
I'm going to make a wild guess here and assume you are using the High
Replication Datastore. Apps which have selected this are presently
running on a set of machines that have the properties you describe.
Rather than having idle instance processes evicted after some number
of minutes,
We're working on it.
On Wed, Sep 7, 2011 at 4:44 AM, Per per.fragem...@gmail.com wrote:
Same problem here. Two of my apps are stuck 5 days ago. But the one
that I disabled the always-on option is showing a 2 day old billing,
and that's actually already taking into account my change in the
Hi Raymond,
Indeed, this is the down-side to tuning the performance setting knobs
to favor cost over performance. Serving latency and reliability may
become worse.
The design of the scheduler is that the default automatic mode decides
to minimize pending latency, and provide spare capacity (to
Hi Pol,
I think I have a change that will fix this, which should be available
once 1.5.4 is pushed out. What is the app-id here?
On Mon, Sep 5, 2011 at 10:41 AM, Pol i...@pol-online.net wrote:
Hi,
Our app settings are as follow:
- Python + HRD
- Max Idle Instances: ( 2 )
- Min Pending
What's the projected bill like now that you've set max-idle-instances?
On Wed, Aug 31, 2011 at 10:07 PM, Brandon Wirtz drak...@digerat.com wrote:
As many of you know, I am strong supporter of the GAE Community. I was an
Early Adopter, and I have defended many of the decisions Google has made.
Hi Tim,
As Dani explained, if there are no instances that have received a
request in the last 15 minutes, then the billable-instances-rate for
that time period is indeed 0. So, in your last example, the
billable-instances for the day would be 4. I'm happy to walk through
other scenarios if you'd
of instances in 3
minutes and I pay for those for the next 15.
** **
** **
*From:* google-appengine@googlegroups.com [mailto:
google-appengine@googlegroups.com] *On Behalf Of *Jon McAlister
*Sent:* Wednesday, September 07, 2011 1:56 PM
*To:* google-appengine@googlegroups.com
*Subject:* Re
Hi Vivek,
It's a good point. The most simple advice I'd have for you is to
follow this rubric:
(1) If you're unhappy with the cost, reduce max-idle-instances.
(2) If you're unhappy with the serving latency and reliability,
increase max-idle-instances.
I think that's really all that most
Hi Tammo,
Let me summarize the case you describe, to make sure I get it right.
First, the app has a period of five minutes, wherein there are four
instances that are active the entire five minutes. Then, the app gets
no more traffic all day. Also, you have max-idle-instances set to 1.
It helps
Glad to hear!
On Tue, Sep 6, 2011 at 7:14 AM, Simon Knott knott.si...@gmail.com wrote:
Thanks for the description Jon, that clears up a lot of my misunderstanding!
--
You received this message because you are subscribed to the Google Groups
Google App Engine group.
To view this discussion
Hi Dani,
I assume you are talking about 'drag-2-share' here? Even if the
instance is still running, it won't matter if it has not received a
request in the last 15 minutes. This is why your Instances graph on
your dashboard is usually 0, occasionally 1 for 15 minutes, and then 0
again. You are
Hi Tammo,
} there is a startup fee of 15 minutes for each instance.
This only affects the computation of the total-instances variable
in the formula, it does not affect the computation of
active-instances.
} - If I understand your calculation correctly, by setting max-idle-
} instances to 1 I
Hi GAEfan,
Instances that have not received a request in the last 15 minutes are
completely ignored by the billing formula. They may be still running
[if hosted on fortuitous machines], and as such are technically
beneficial to you in that you avoid extra loading requests, but we eat
that cost.
Hi Jon and Alexis,
Indeed by default the scheduler will try to make space for spare
capacity in your frontend instances. There are usually two reasons for
this.
The first is that requests do not usually come in regularly, they
arrive in spikes and various irregular patterns. In order to
Hi Dani,
If you have set max-idle-instances=1, then in that example, what would
happen is:
(a) Instance is active 1 second every 5 minutes.
(b) That is 288 active seconds for the day.
(c) active-instances-rate is = 288/60*60*24 = 0.0033 for whole day
(d) total-instances-rate = 1 for whole day
Hi Deepak,
It is not possible to set max-idle-instances to 0. If you had set
max-idle-instances to 1, then your example is basically identical to
Dani's.
On Tue, Sep 6, 2011 at 11:31 AM, Deepak Singh deepaksingh...@gmail.com wrote:
Suppose, i have set my max-idle-instance to 0. And i have
it affect the bill
as cron job does not do anything means does not use any resources.
Thanks
On Wed, Sep 7, 2011 at 12:03 AM, Jon McAlister jon...@google.com wrote:
Hi Deepak,
It is not possible to set max-idle-instances to 0. If you had set
max-idle-instances to 1, then your example is basically
and run a cron job every min or every 15 min to
ensure that at least one instance is available.
And i have set max-idle-instance to either 1 or Automatic.
The App may have or may not have traffic.
Thanks
On Wed, Sep 7, 2011 at 12:12 AM, Jon McAlister jon...@google.com wrote:
I probably don't
Hi Tim,
In your case, I think what would suit you well is to set
max-idle-instances=1 (you've already done that) and
min-idle-instances=1. The latter knob is not yet available but will be
available once the pricing rollout is complete. In the short-term you
could have a cron job keep your
of application. So i need
to understand it.
Thanks
On Wed, Sep 7, 2011 at 1:10 AM, Barry Hunter barrybhun...@gmail.com wrote:
Maybe it's a request to have a min-idle-instance setting added?
because that doesn't exist yet...
On Tue, Sep 6, 2011 at 8:17 PM, Jon McAlister jon...@google.com wrote
Hi millisecond, I can illuminate some of the issues here.
As Johan said, the bill will be based on active-instances [the orange
line] plus max-idle-instances. That is correct.
I can see though how your 09-01 billing report is confusing though, I
can explain that. Also, I'm very sorry that the
application.
I'll take a look at the new billing statement in the morning (I'm
central european time) and see what I can tell.
On Sep 5, 10:49 pm, Jon McAlister jon...@google.com wrote:
Hi millisecond, I can illuminate some of the issues here.
As Johan said, the bill will be based on active
Hi Mike, I can help explain some of the issues going on here.
For starters, if an app is thread-safe, then yes that is a very
important signal to the scheduler. It indicates that an instance
can sustain more requests and as such there is no need to place
the incoming request on a pending queue
It's because appspot.com was added to the public suffix list of
domains that modern browsers should not allow cookies to be set for:
http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1
On Thu, Aug 18, 2011 at 8:53 AM, Joshua Smith joshuaesm...@charter.net
@Per, thanks for the data, that is very helpful! There are a
couple of things going on here. The first is that it is spinning
up several new dynamic instances at a time. That's definitely a
bug, and I've confirmed why its happening. We'll fix that for the
next release.
For your warmup requests, I
On Sat, Jul 30, 2011 at 11:44 PM, Robert Kluin robert.kl...@gmail.com wrote:
This whole thread is an excellent example of why I'm not at all enthusiastic
about the new pricing.
Mike is 100% correct, this behavior is amazing unintuative and confusing.
If we will be paying around $60 per month
that will interact with an appengine
app,
but if that appengine app uses the lib too, the headers will be missing...
:(
Cheers :)
-Andrin
On Tue, Jul 26, 2011 at 5:24 PM, Jon McAlister jon...@google.com wrote:
I should also point out that, while this header is not yet documented,
it's not going away
:18 PM, Jon McAlister jon...@google.com wrote:
Right now it's only being sent when the request is to an appspot.com
url. Is that the case in your example?
On Fri, Jul 29, 2011 at 9:40 AM, MiuMeet Support r...@miumeet.com wrote:
Why isn't this header present if I call my own app from my app?
I'm
them when you're
under heavy load?
http://dl.dropbox.com/u/473572/Untitled2.jpg
Wouldn't I be charged for 6 instance under the new pricing model when
I'm only really using 3?
On Jul 27, 7:12 pm, Jon McAlister jon...@google.com wrote:
So, there's a couple of things going on here. I'll see if I
So, there's a couple of things going on here. I'll see if I can help explain.
The first is that with 1.5.2 we changed how resident instances work,
so that if a dynamic instance existed, the scheduler would prefer an
idle dynamic instance to an idle resident instance. Further, if a
resident
Yes, you can assume this.
The only cases where this header will be allowed through to the app are:
(a) another app is requesting your app using our urlfetch api [or,
the app is urlfetching itself]
(b) the request came from a logged-in admin of your app
While (a) is the primary intention
I should also point out that, while this header is not yet documented,
it's not going away either, and will be documented in an upcoming
release.
On Tue, Jul 26, 2011 at 8:23 AM, Jon McAlister jon...@google.com wrote:
Yes, you can assume this.
The only cases where this header will be allowed
Indeed that is the expected behavior for that scenario. If you'd like the
alternate behavior, wherein the user is logged out of your app but not out
of Google Accounts, then what you should do instead is delete the [S]ACSID
cookie with a Set-Cookie: header in your response. After that, the user
On Jun 21, 1:25 pm, Jon McAlister jon...@google.com wrote:
Hi Tom,
I'm not sure about the servlet context listener code.
However, thanks for pointing out the behavior of the interaction of
loading requests and threadsafe apps. We are indeed sending down
non-loading-requests while
Hi Tom,
I'm not sure about the servlet context listener code.
However, thanks for pointing out the behavior of the interaction of
loading requests and threadsafe apps. We are indeed sending down
non-loading-requests while the instance is still processing the
loading request. This is problematic
The header is enabled now.
On Tue, Jun 21, 2011 at 11:21 AM, Gregory D'alesandre gr...@google.com wrote:
Sorry about that, we are in the process of turning this on, I'll let you
know when it is complete.
Greg
On Tue, Jun 21, 2011 at 10:50 AM, Felippe Bueno felippe.bu...@gmail.com
wrote:
To log the user out of just your app, but not out of google, just
delete the ACSID or SACSID cookie from your domain.
On Wed, May 4, 2011 at 9:33 AM, hst hstoer...@gmail.com wrote:
Hi,
I have an app for which I enabled login via google accounts with the user
api. I proceeded following the
);
is called. In this case both apps have appspot.com urls and
it worked well. We are dead in the water now.
Please help!
Thanks,
Glenn
On Mar 2, 12:31 pm, Jon McAlister jon...@google.com wrote:
Looks like you pushed a good workaround already, but yes that was a
result of a new login system
Looks like you pushed a good workaround already, but yes that was a
result of a new login system yesterday, and looks like it is not
handling this case like the prior system did.
Specifically, calling createLoginUrl where the continue url is not the
same as the url the app is hosted on. And,
Yes, this is a known bug :-(. Specifically, if the user is asked for
alternative contact info (e.g. sms) for account recovery purposes, the
redirect to the rest of the login flow results in this error.
We are working on the fix, it may take a few weeks to be live though.
On Wed, Mar 2, 2011 at
Sorry about that. We were just testing out a change, but it does not
work for a certain class of google accounts. Have reverted the change
so it should be working again.
On Wed, Feb 16, 2011 at 4:23 PM, Rahul Kumar rahulsin...@gmail.com wrote:
Does anyone know yet what happened and when is it
Sorry about that. We were just testing out a change, but it does not
work for a certain class of google accounts. Have reverted the change
so it should be working again.
On Wed, Feb 16, 2011 at 4:14 PM, Rahul Kumar rahulsin...@gmail.com wrote:
Hi,
App Engine is giving me Server Error when I try
Sorry about that. We were just testing out a change, but it does not
work for a certain class of google accounts. Have reverted the change
so it should be working again.
On Wed, Feb 16, 2011 at 3:09 PM, fross-pe...@conceptuamath.com
fross-pe...@conceptuamath.com wrote:
When I go here:
Sorry about that. We were just testing out a change, but it does not
work for a certain class of google accounts. Have reverted the change
so it should be working again.
On Wed, Feb 16, 2011 at 2:50 PM, chingon27 chingo...@gmail.com wrote:
same here. after logging in I get a 500 server error.
and today, 12/11, I had 14 loading requests. They are all user
requests, there is no warmup request to /_ah/warmup. Same thing yesterday:
37 loading requests, not a single one to /_ah/warmup. I think it's still not
fixed...
Thanks again
Sergio
On Fri, Dec 10, 2010 at 23:13, Jon McAlister jon
Hi Sergio,
I looked into your app, and unfortunately we had a slight
configuration error on our part. This has now been fixed and pushed
out. So, it should be significantly better now. Mind having another
look?
On Wed, Dec 8, 2010 at 5:49 PM, Sergio Lopes slo...@gmail.com wrote:
Hi guys
I
This is a new logging message we just added. You've most likely had
clones exceed the soft memory limit forever, but now we are letting
you know via logs. These logs can of course be ignored if you like,
since it doesn't effect the http response you served, but if you are
concerned about
Yep, we had a bad admin console push and deploys were affected
from 3:10pm PST until 4:30pm PST. All better now. Apologies.
On Thu, Mar 18, 2010 at 3:50 PM, Huebi konrad.hueb...@googlemail.com wrote:
here as well :(
On 18 Mrz., 23:42, François Masurel fm2...@mably.com wrote:
Same problem here
Yep, we had a bad admin console push and deploys were affected
from 3:10pm PST until 4:30pm PST. All better now. Apologies.
On Thu, Mar 18, 2010 at 4:23 PM, Staz steve.le...@yahoo.com wrote:
+1
--
You received this message because you are subscribed to the Google Groups
Google App Engine
Yep, I see what you mean, looking into it. Thanks for the report.
On Wed, Dec 2, 2009 at 10:55 PM, oldcomputer computer...@yahoo.com wrote:
says report,, gives server 500 error at system status page
--
You received this message because you are subscribed to the Google Groups
Google App
Fixed now. Apologies for the outage.
On Thu, Dec 3, 2009 at 8:29 AM, Jon McAlister jon...@google.com wrote:
Yep, I see what you mean, looking into it. Thanks for the report.
On Wed, Dec 2, 2009 at 10:55 PM, oldcomputer computer...@yahoo.com wrote:
says report,, gives server 500 error
No, there will not be periodic maintenances for task queues like there
are for datastore.
On Thu, Oct 22, 2009 at 12:59 AM, djidjadji djidja...@gmail.com wrote:
Will the Task Queue systems ever be under maintenance?
2009/10/19 Jon McAlister jon...@google.com:
Yep. The latency of execution
There was an issue with 1.2.6 in that it throughput on task queue requests was
getting unfairly throttled. This has now been fixed. Apologies for the bug and
for the confusion.
On Wed, Oct 14, 2009 at 12:51 PM, Picalolabu
manuel.martin.agui...@gmail.com wrote:
Created a new issue for this
There was an issue with 1.2.6 in that it throughput on task queue requests was
getting unfairly throttled. This has now been fixed. Apologies for the bug and
for the confusion.
On Wed, Oct 14, 2009 at 12:06 PM, divricean divric...@gmail.com wrote:
I can confirm this exact behavior. Except
jacob-6 is currently on 1.2.5 but I'll be moving it to 1.2.6 later on
today now that we've fixed the underlying bugs in 1.2.5. Apologies
again for the confusion.
On Wed, Oct 14, 2009 at 10:21 AM, bvelasquez bvelasq...@gmail.com wrote:
Just checking the status of this. My app was moved to the
There was an issue with 1.2.6 in that it throughput on task queue requests was
getting unfairly throttled. This has now been fixed. Apologies for the bug and
for the confusion.
On Tue, Oct 13, 2009 at 11:13 PM, ajalsen ajen.al...@gmail.com wrote:
then why it is happening with my code?
Yes,
It's an issue in the 1.2.6 release we're pushing out to the backends
today. If you tell me your app id (off-list is ok) I can move your app
to a 1.2.5 appserver and that will fix this your app.
And yes, we're working on a real fix too right now.
On Mon, Oct 12, 2009 at 3:47 PM, bvelasquez
It's an issue in the 1.2.6 release we're pushing out to the backends
today. I've moved your app to a 1.2.5 appserver to temporarily fix it.
And yes, we're working on a real fix too right now.
On Mon, Oct 12, 2009 at 3:48 PM, nasim nasim.ha...@gmail.com wrote:
I am getting this error in my
Moved dnzo.
On Mon, Oct 12, 2009 at 4:03 PM, Taylor Hughes tay...@taylorhugh.es wrote:
My app is also affected; the app key is dnzo if you could also push me
back to 1.2.5 for now I'd appreciate it.
On Oct 12, 3:51 pm, Jon McAlister jon...@google.com wrote:
It's an issue in the 1.2.6
Yes this is also another transient bug. Will be gone a midnight PST.
On Wed, Oct 7, 2009 at 7:57 PM, jack yaoye...@gmail.com wrote:
Yeah, I got this too on my several gae sites,
High Cpu Http Requests 90% 8262604116349070336 of
9223372036854775808
...
On Oct 7, 7:02 pm, Jason Smith
This is a transient bug that you can ignore. Will be gone a midnight PST.
On Wed, Oct 7, 2009 at 6:43 PM, Sargis Dallakyan food@gmail.com wrote:
Greetings,
I just checked my app and noticed a new entry called High Cpu Http
Requests in the Dashboard. When I click on Quota Details, it's
Workaround documented at
http://code.google.com/p/googleappengine/issues/detail?id=744.
Apologies for the confusion.
On Mon, Jul 20, 2009 at 7:07 AM, Federico
Builesfederico.bui...@gmail.com wrote:
On Jul 19, 4:24 pm, Federico Builes federico.bui...@gmail.com wrote:
When I log into my
Workaround documented at
http://code.google.com/p/googleappengine/issues/detail?id=744.
Apologies for the confusion.
On Mon, Jul 20, 2009 at 7:36 PM, Benbhym...@gmail.com wrote:
This usually means you have too many versions in the management
console. try deleting some of the versions you
Workaround documented at
http://code.google.com/p/googleappengine/issues/detail?id=744.
Apologies for the confusion.
On Tue, Jul 21, 2009 at 3:48 PM, Jeremy Truaxtrup...@gmail.com wrote:
Here's the issue about it:
http://code.google.com/p/googleappengine/issues/detail?id=744
I still am
Workaround documented at
http://code.google.com/p/googleappengine/issues/detail?id=744.
Apologies for the confusion.
On Fri, May 29, 2009 at 12:12 AM,
bwh...@dappervision.come133tc1p...@gmail.com wrote:
Was at version 1 (only version) and version 2 didn't fix it but
version 3 did the trick!
Workaround documented at
http://code.google.com/p/googleappengine/issues/detail?id=744.
Apologies for the confusion.
On Fri, Jun 26, 2009 at 9:11 PM, Stephen Mayerstephen.ma...@gmail.com wrote:
How many deployments are you currently using? If you delete a few old
ones it will probably let
1 - 100 of 157 matches
Mail list logo
