[google-appengine] Re: Channel API future improvements?

[Kristopher Giesing]

This is logged here:

http://code.google.com/p/googleappengine/issues/detail?id=7098

I patched the 1.7 channel API locally to deal with it; see the issue 
comments.

On Saturday, March 5, 2011 8:02:23 AM UTC-8, Westmark wrote:
>
> Is there any way for the client to terminate the connection while 
> running on the development server? I've tried calling close() and 
> every other function I can find on the socket and client javascript 
> object, but it keeps polling forever. I want to be able to kill it off 
> so I can setup a new connection with a fresh token without the browser 
> going nuts with requests. 
>
> BR // Fredrik 
>
>
> On 7 Feb, 18:15, Tim  wrote: 
> > On Monday, February 7, 2011 5:05:06 PM UTC, Peter Petrov wrote: 
> > 
> > > You can change the dev-server polling interval in your JavaScript code 
> > > quite easily. For example: 
> > 
> > > goog.appengine.Socket.POLLING_TIMEOUT_MS = 5000; // 5 seconds 
> > 
> > Ah, so you can... and here was me looking for ways to get hold of the 
> > goog.Timer objects or similar. 
> > 
> > And changing that value on the fly changes the timeout for the next call 
> (ie 
> > it's not something you can only change before creating a channel) - 
> > thanks... I feel quite foolish now :) 
> > 
> > -- 
> > T

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/8FzGn8jhStQJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Intermittent errors (302) in communicating from a backend instance to another app via the remote api

[Kristopher Giesing]

I've seen 302 errors come from API calls to GAE apps where I accessed the 
origin page with http://, and sent the API call relative to the page (thus 
also using http://), but the API endpoint requires https://.  Could this be 
related?

- Kris

PS. I've been pondering whether this is a bug, since 302 implies that the 
caller should continue to use the original URL, and in my case the https 
protection is permanent. I might have expected 403 or 404 instead.

On Thursday, July 26, 2012 7:39:16 AM UTC-7, John Kelvie wrote:
>
> We are getting, on occasion, 302 errors in communicating from a backend to 
> another app via the remote API. Once the errors start, they occur 
> continuously until we stop and start the backend. Has anyone else 
> encountered this? Is there a way to resolve it that does not involve 
> restarting the backend instance?
>
> -John
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/RzkgYxRyk7EJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Need help: Pathological instancing behavior

[Kristopher Giesing]

I've been working for some time on an app I plan to deploy.  Over the 
development period I have done testing on the QA instance of my app (which 
is a separate app ID from the one I'll use in production) but have not paid 
serious attention to performance since the functionality wasn't yet 
complete.

This past weekend I did some light real-world type testing, and the 
performance was terrible.  With QPS in the 5-10 range I was seeing 
latencies in the range of 10-20s.  Obviously, the first place I looked was 
my own code, but after some easy optimizations I got my query handling down 
to the 200ms range, and the response times on the client were still usually 
very bad (1s minimum, up to 10-20s max).  (Pings from the client to the 
appspot.com domain are pretty stable at 30ms.)

Looking further, I discovered that Google App Engine is spawning new 
instances of my app at a pathological rate.  For example, I left the app 
stats console open for a while, and found that just loading the appstats 
URI by itself would cause a new instance to spawn!  This is with zero QPS 
otherwise - my app was completely idle, and none of my own code was running 
at all.

I tried adjusting the min and max instance settings, but GAE seems to 
ignore them, as far as I can tell; the max is not honored, and although it 
does keep instances running to accommodate the min, those running instances 
don't prevent new ones from spawning.  It's as if GAE doesn't think they 
really exist. I also have the min latency set to the max of 15.0s, which is 
far beyond the rise time I'm seeing for GAE spawning new instances. 

Here's a set of logs taken from a very light load on the server, with a 2/2 
instance max/min setting.  I include logs from a previous slice of time so 
that you can see the /appstats URI also spawning new instances, but I want 
to emphasize that this is a continuous set of logs - there are no requests 
in this time window that aren't listed below.  I also include a screenshot 
of the instance panel in the console so you can see that the instances are, 
in fact, being created.

2012-07-31 18:58:12.541 /_ah/channel/connected/ 200 101ms 0kb
2012-07-31 18:58:10.894 /api/chat/G:1286432802 200 132ms 0kb Mozilla/5.0 
(iPad; CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) 
Mobile/9B206
2012-07-31 18:58:09.809 /_ah/channel/connected/ 200 1076ms 0kb
2012-07-31 18:58:09.107 /api/game/72001/users 200 12312ms 0kb Mozilla/5.0 
(iPad; CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) 
Mobile/9B206
2012-07-31 18:58:07.725 /api/chat/G:658732847 200 7232ms 0kb Mozilla/5.0 
(iPad; CPU OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) 
Mobile/9B176
2012-07-31 18:58:00.279 /api/game/72001/users 200 8820ms 0kb Mozilla/5.0 
(iPad; CPU OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) 
Mobile/9B176
I 2012-07-31 18:58:00.279 This request caused a new process to be started 
for your application, and thus caused your application code to be loaded 
for the first time. This requ
2012-07-31 18:57:56.393 /api/game/72001 200 6044ms 3kb Mozilla/5.0 (iPad; 
CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) 
Mobile/9B206
2012-07-31 18:57:55.920 /_ah/warmup 200 5105ms 0kb
I 2012-07-31 18:57:55.916 This request caused a new process to be started 
for your application, and thus caused your application code to be loaded 
for the first time. This requ
2012-07-31 18:57:51.324 /api/game/72001 200 7151ms 3kb Mozilla/5.0 (iPad; 
CPU OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) 
Mobile/9B176
2012-07-31 18:57:49.779 /_ah/warmup 200 4629ms 0kb
I 2012-07-31 18:57:49.778 This request caused a new process to be started 
for your application, and thus caused your application code to be loaded 
for the first time. This requ
2012-07-31 18:57:01.504 /_ah/warmup 200 5225ms 0kb
I 2012-07-31 18:57:01.503 This request caused a new process to be started 
for your application, and thus caused your application code to be loaded 
for the first time. This requ
2012-07-31 18:13:56.599 /_ah/warmup 200 4784ms 0kb
I 2012-07-31 18:13:56.581 This request caused a new process to be started 
for your application, and thus caused your application code to be loaded 
for the first time. This requ
2012-07-31 18:06:53.651 /appstats/stats 200 898ms 285kb Mozilla/5.0 
(Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, like Gecko) 
Version/6.0 Safari/536.25
2012-07-31 18:06:52.618 /appstats 302 33ms 0kb Mozilla/5.0 (Macintosh; 
Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, like Gecko) Version/6.0 
Safari/536.25
2012-07-31 18:06:14.538 /appstats/static/plus.gif 200 45ms 0kb Mozilla/5.0 
(Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, like Gecko) 
Version/6.0 Safari/536.25
2012-07-31 18:06:14.298 /appstats/static/app_engine_logo_sm.gif 200 4820ms 
3kb Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 
(KHTML, like Gecko) Version/6.0 Safari/536.25
2012-07-31 18:06:14.

Re: [google-appengine] Instances/Java go crazy

[Kristopher Giesing]

Just noticed this thread.  I'm seeing this as well.  More details here:

https://groups.google.com/forum/?fromgroups#!topic/google-appengine/rjZhjMEAXUI

On Monday, July 30, 2012 9:37:08 AM UTC-7, Mos wrote:
>
> > Which runtime you are using? 
>
> GAE/Java 2.7 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/wpyD_zZ0Ql0J.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Need help: Pathological instancing behavior

[Kristopher Giesing]

Hi Takashi,

Thanks for the prompt response.  Info below...

On Tuesday, July 31, 2012 8:30:58 PM UTC-7, Takashi Matsuo (Google) wrote:
>
> Hi Kristopher, 
>
> Where are you accessing your app from? Ping result is just for our 
> frontend facilities, so it doesn't reflect the real network latency of 
> your app. 
>

I'm physically in Palo Alto, CA.  Do you need more detail than that?  I can 
run a traceroute if that helps.
 

> > 
> > Looking further, I discovered that Google App Engine is spawning new 
> > instances of my app at a pathological rate.  For example, I left the app 
> > stats console open for a while, and found that just loading the appstats 
> URI 
> > by itself would cause a new instance to spawn!  This is with zero QPS 
> > otherwise - my app was completely idle, and none of my own code was 
> running 
> > at all. 
>
> Sorry if I miss something, but I think it's the expected behavior. If 
> you don't set min idle instances, your app doesn't need to have any 
> instances with zero QPS, right? So if there's a new request, App 
> Engine spins up a new instance for your application. 
>

Right, sorry, this part was not very clear.

In this particular case, I had min (and max) instances set to 1.  So there 
was (should have been) an instance already running, and from the logs it 
was idle.

I can set this case up again if you like and gather more details.

I think the cause of the high latency is the user facing loading requests. 
>
> Can you try something like min idle instances=5(or 10)/max idle 
> instances=automatic, and see how it goes first? Currently setting 'min 
> idle instances' is the most reliable way to reduce user facing loading 
> requests. Additionally, you shouldn't set 'max idle instances' because 
> if you set max idle instances, App Engine will terminate your idle 
> instances aggressively, as a result you will see more user facing 
> loading requests.
>

I can try that.  That was actually the point of bumping up the min 
instances to 2 (whereas previously it was 1).  The fact that five instances 
were spawned is baffling to me because there really weren't that many 
requests - from the logs, it looks to me as if GAE spawned three new 
instances after receiving the very first request, despite there being two 
idle instances ready to handle it.

I'm wondering if I would have better luck with a backend for this.  This is 
an Ajax application where the HTML is locally embedded in an iOS app, so 
there's really no frontend in the traditional sense.

- Kris

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/1u6A2_1Iz9cJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Need help: Pathological instancing behavior

[Kristopher Giesing]

So, this behavior is completely reproducible.

1) Shut down all instances.
2) Set min instances to 1 (leave all other sliders at default values).
3) Save settings and wait for instance to spin up.
4) Issue one GET request from browser to a specific API endpoint.  This is 
an API call so it is not multiplexing into additional requests the way, 
say, an HTML page fetch would (to get css, images, etc). It really is just 
one call.
5) Note that Google App Engine spins up a new instance to handle the 
request.

Here are the logs from this; there are no other events within two minutes 
of this window of time:

2012-07-31 23:08:28.045 /api/game/57002?pretty=true 200 7893ms 11kb 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
like Gecko) Version/6.0 Safari/536.25
76.102.149.245 - kris [31/Jul/2012:23:08:28 -0700] "GET 
/api/game/57002?pretty=true HTTP/1.1" 200 11652 - "Mozilla/5.0 (Macintosh; 
Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, like Gecko) Version/6.0 
Safari/536.25" "titan-game-qa.appspot.com" ms=7893 cpu_ms=3520 api_cpu_ms=0 
cpm_usd=0.099322 instance=00c61b117c77507e2cfe78a0806d0ca80b52720e
2012-07-31 23:08:27.475 /_ah/warmup 200 5873ms 0kb
0.1.0.3 - - [31/Jul/2012:23:08:27 -0700] "GET /_ah/warmup HTTP/1.1" 200 60 
- - "1.360723738856412175.titan-game-qa.appspot.com" ms=5873 cpu_ms=2475 
api_cpu_ms=0 cpm_usd=0.068778 loading_request=1 
instance=00c61b117cdaae6145945d99c16aeee7cc0f4ad8
I 2012-07-31 23:08:27.466
This request caused a new process to be started for your application, and 
thus caused your application code to be loaded for the first time. This 
request may thus take longer and use more CPU than a typical request for 
your application.
2012-07-31 23:07:42.842 /_ah/warmup 200 5045ms 0kb
0.1.0.3 - - [31/Jul/2012:23:07:42 -0700] "GET /_ah/warmup HTTP/1.1" 200 60 
- - "1.360723738856412175.titan-game-qa.appspot.com" ms=5046 cpu_ms=2475 
api_cpu_ms=0 cpm_usd=0.068778 loading_request=1 
instance=00c61b117c77507e2cfe78a0806d0ca80b52720e
I 2012-07-31 23:07:42.841
This request caused a new process to be started for your application, and 
thus caused your application code to be loaded for the first time. This 
request may thus take longer and use more CPU than a typical request for 
your application.

Spinning up 10 instances doesn't help.  I refreshed this GET at somewhat 
irregular intervals for about thirty seconds, and GAE spun up five new 
instances, despite not being even close to out of headroom:

2012-07-31 23:17:02.178 /api/game/57002?pretty=true 200 4744ms 11kb 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
like Gecko) Version/6.0 Safari/536.25
2012-07-31 23:17:02.177 /api/game/57002?pretty=true 200 5770ms 11kb 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
like Gecko) Version/6.0 Safari/536.25
2012-07-31 23:16:59.793 /api/game/57002?pretty=true 200 1311ms 11kb 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
like Gecko) Version/6.0 Safari/536.25
2012-07-31 23:16:57.844 /api/game/57002?pretty=true 200 2618ms 11kb 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
like Gecko) Version/6.0 Safari/536.25
2012-07-31 23:16:57.843 /api/game/57002?pretty=true 200 5619ms 11kb 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
like Gecko) Version/6.0 Safari/536.25
2012-07-31 23:16:54.623 /api/game/57002?pretty=true 200 309ms 11kb 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
like Gecko) Version/6.0 Safari/536.25
2012-07-31 23:16:51.911 /_ah/warmup 200 2942ms 0kb
I 2012-07-31 23:16:51.911 This request caused a new process to be started 
for your application, and thus caused your application code to be loaded 
for the first time. This requ
2012-07-31 23:16:51.622 /api/game/57002?pretty=true 200 174ms 11kb 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
like Gecko) Version/6.0 Safari/536.25
2012-07-31 23:16:50.915 /api/game/57002?pretty=true 200 2664ms 11kb 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
like Gecko) Version/6.0 Safari/536.25
2012-07-31 23:16:47.720 /api/game/57002?pretty=true 200 557ms 11kb 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
like Gecko) Version/6.0 Safari/536.25
2012-07-31 23:16:47.286 /_ah/warmup 200 4823ms 0kb
I 2012-07-31 23:16:47.285 This request caused a new process to be started 
for your application, and thus caused your application code to be loaded 
for the first time. This requ
2012-07-31 23:16:46.377 /api/game/57002?pretty=true 200 5360ms 11kb 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
like Gecko) Version/6.0 Safari/536.25
2012-07-31 23:16:40.500 /api/game/57002?pretty=true 200 1828ms 11kb 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
like Gecko) Version/6.0 Safari/536.25
2012-07-31 23:16:37.969 /api/game/57002?pretty=true 20

Re: [google-appengine] Need help: Pathological instancing behavior

[Kristopher Giesing]

The above post notwithstanding, the original problem I was having - which 
caused me to try to set min instances to 1 to begin with - seems to have 
gone away.  I know this is probably going to fall into the PEBCAK bucket, 
but I really don't think I did anything in particular to cause the problem, 
so I will explain in somewhat tedious detail the circumstances surrounding 
the problem, even if some of them aren't relevant.

The original problem was that the client-side latency of requests was 
intermittently very high.  I don't have many details on this because as 
soon as I tried to diagnose it I ran into the problem outlined above, which 
certainly confused my investigation.

However, now that I realize that the min instance slider is basically 
useless to me, I went back to testing against the auto/auto settings which 
I was using to begin with.  I then noticed that the appstats endpoint was 
getting hit at times I didn't expect.  To try to diagnose the problem with 
A/B testing I deleted all references to appstats and re-deployed my app. 
 Sure enough, the mysteriously high latency disappeared.  Confident I was 
on to something, I put appstats back, and the problem failed to reappear.

So now the performance of the app is in the range that I would expect.  The 
client-side latency is around a second, which is not great by many 
standards, but is sort-of OK for my application and is certainly better 
than 5+ seconds.  It's also closer to what I see inside the request 
handling itself - that is, when client latency is higher, so is the 
accumulated latency inside the request handler (from internal data 
manipulation etc).  This gives me the lever of optimizing my own calls to 
avoid occasionally-expensive operations, so it's much less of an issue; 
prior to this, the vast majority of the latency happened outside the 
request handling where I don't have any control.

If the performance of GAE generally is in the range I'm seeing now, that's 
a shippable product in my mind.  I am worried, however, that the problem 
was somewhere else in the system and somewhere down the line I will be hit 
with this problem again, only it will be in production and users will 
rightly complain that their experience is suffering.

So any further comment on this issue would be very welcome.  I'm still 
considering whether a backend is a more appropriate vehicle for this 
functionality.

Thanks,

- Kris

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/bF1zbyVA1BQJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Need help: Pathological instancing behavior

[Kristopher Giesing]

I spoke too soon.  Some time after posting this, testing revealed more 
problems.  Upon diagnosis, it appears that GAE is too aggressive at 
spinning up new instances even when the "auto/auto" setting is used, 
although the behavior is less reproducible than when a min of 1 is set.

The only fix I found for this was to switch to using a backend.  With a 
backend I can control exactly how many instances are used.  A single 
instance is sufficient for me and the RTT is now down to about 400-500ms 
(measured from the client), which is completely satisfactory.

What is *not* so satisfactory is (a) backends are more expensive than 
frontends, and I'm basically paying in order not to use a feature, which I 
find pretty annoying; and (b) this breaks my site in half and I will now 
have to worry about cross-domain scripting when I eventually get to the 
point of having an actual web interface (and not just APIs called by a 
native app).

Something is clearly broken about frontend instance balancing.  I'm 
guessing it's only broken at the lower end of the traffic scale or no one 
would be using GAE, but it's broken nonetheless.  You could argue that GAE 
is built to scale up, not down, but GAE balancing is currently an *order of 
magnitude* worse than a naive solution for this problem domain; so even 
though the pervasiveness might be low, the severity is very high.  IMHO 
this needs to be fixed.

- Kris

On Tuesday, July 31, 2012 11:35:50 PM UTC-7, Kristopher Giesing wrote:
>
> The above post notwithstanding, the original problem I was having - which 
> caused me to try to set min instances to 1 to begin with - seems to have 
> gone away.  I know this is probably going to fall into the PEBCAK bucket, 
> but I really don't think I did anything in particular to cause the problem, 
> so I will explain in somewhat tedious detail the circumstances surrounding 
> the problem, even if some of them aren't relevant.
>
> The original problem was that the client-side latency of requests was 
> intermittently very high.  I don't have many details on this because as 
> soon as I tried to diagnose it I ran into the problem outlined above, which 
> certainly confused my investigation.
>
> However, now that I realize that the min instance slider is basically 
> useless to me, I went back to testing against the auto/auto settings which 
> I was using to begin with.  I then noticed that the appstats endpoint was 
> getting hit at times I didn't expect.  To try to diagnose the problem with 
> A/B testing I deleted all references to appstats and re-deployed my app. 
>  Sure enough, the mysteriously high latency disappeared.  Confident I was 
> on to something, I put appstats back, and the problem failed to reappear.
>
> So now the performance of the app is in the range that I would expect. 
>  The client-side latency is around a second, which is not great by many 
> standards, but is sort-of OK for my application and is certainly better 
> than 5+ seconds.  It's also closer to what I see inside the request 
> handling itself - that is, when client latency is higher, so is the 
> accumulated latency inside the request handler (from internal data 
> manipulation etc).  This gives me the lever of optimizing my own calls to 
> avoid occasionally-expensive operations, so it's much less of an issue; 
> prior to this, the vast majority of the latency happened outside the 
> request handling where I don't have any control.
>
> If the performance of GAE generally is in the range I'm seeing now, that's 
> a shippable product in my mind.  I am worried, however, that the problem 
> was somewhere else in the system and somewhere down the line I will be hit 
> with this problem again, only it will be in production and users will 
> rightly complain that their experience is suffering.
>
> So any further comment on this issue would be very welcome.  I'm still 
> considering whether a backend is a more appropriate vehicle for this 
> functionality.
>
> Thanks,
>
> - Kris
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/_v9CmfpUmQ4J.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Need help: Pathological instancing behavior

[Kristopher Giesing]

PS.  I once again encountered evidence that appstats is causing requests to 
fire even when I'm not actively using the management console, which is very 
weird.  I've turned off appstats because I didn't really find it all that 
useful anyway (and because it causes the dev server not to start when you 
have backends enabled).

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/ELQ1qTByrhEJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Boat Load of Questions (which might turn in to feature requests)

[Kristopher Giesing]

On Sunday, July 29, 2012 12:43:31 PM UTC-7, Brandon Wirtz wrote:
>
> Why can’t I configure how many requests a backend can handle? Or have a 
> back end act like a front end and handle 8?
>
The Java version has an experimental field in backends.xml called 
max-concurrent-requests.  I would assume Python will get the same at some 
point.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/KOvXcx3NZBgJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Backend performance, compared

[Kristopher Giesing]

Terrifying.

So, I assume Richard's medium-term plan is to set up an "outboard" 
collector endpoint, and have a single GAE backend reap from that?

- Kris

On Tuesday, August 7, 2012 7:10:43 PM UTC-7, Jeff Schnitzer wrote:
>
> If you've been reading various threads on this list you know that 
> Richard has been having trouble getting his mobile game to run 
> smoothly on GAE.  It's a little unusual because timing is coordinated 
> precisely: 
>
>  * At T+0, all clients submit scores 
>  * At T+5s, a reaper process aggregates the scores and builds a result set 
>  * At T+10s, all clients fetch scores 
>
> The question is:  Where to submit the score data so that the reaper 
> can fetch and aggregate it? 
>
> Here's some answers that didn't work: 
>
>  * The datastore.  Eventual consistency is too eventual to query for 
> all the scores and get them. 
>  * Pull queues.  There's too much of a delay between task insertion 
> and when it appears for leasing. 
>  * A single backend.  One backend cannot handle more than ~80qps. 
>
> He eventually got a system working reliably, sharded across ten B1 
> instances, at a cost (beyond other charges) of ~$600/mo.  It can 
> collect a couple thousand scores within the 5s deadline (barely). 
>
> I thought this was insane, so I built a few experiments to see what 
> other technologies can do, using the exact program logic of Richard's 
> collector.  Here are the results: 
>
> The environment:  256MB Rackspacecloud VPS running Ubuntu 10.04.4 LTS 
> The cost:  $11/mo 
> The command:  ab -c 1 -n 1 -r http://theurl  (that's 10k 
> requests, all concurrent). 
>
> Node.js:  ~2500 qps.  Rock solid through multiple test runs, all 
> complete before the deadline. 
> Java SimpleHTTP:  ~2100 qps.  Had to bump heap up to 128MB. 
> Python Twisted:  ~1600 qps.  Failed a lot of requests on most test runs. 
> Python Tornado:  ~1500 qps, but rock solid through multiple test runs. 
>
> So basically, an $11/mo VPS server running Javascript vastly exceeds 
> the capabilities of 10 backends at $60/mo each. 
>
> Jeff 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/LArEHI-YEucJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Backend performance, compared

[Kristopher Giesing]

I have a Linode instance.  How do I run the test?


> BTW I picked Rackspace for this test because I happened to already 
> have a VPS there.  I would love to see latency numbers for Linode, 
> EC2, and Google Compute Engine.  Does anyone want to run the test? 
> I'm still waiting for an invite to GCE. 
>
> Jeff 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/TsUUZbNRrt0J.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Backend performance, compared

[Kristopher Giesing]

This is his evidence that higher-use apps have better performance.  I'm not 
surprised that memcache hit rates would be higher (since you're more likely 
to evict your neighbors than vice versa) but the latency difference does 
surprise me.

I wonder if Google's balancing algorithms tend to starve low-qps apps?  I 
can imagine a class of caching behavior that would cause that sort of 
thing, and the caches could be operating at many levels of the stack.

- Kris

On Wednesday, August 8, 2012 8:25:19 PM UTC-7, Jeff Schnitzer wrote:
>
> Why are you posting memcache stats in a thread about backends?
>
> Jeff
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/UjQj9Ejj0gMJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Low hitting site experiencing denial of service attack - site opffline!

[Kristopher Giesing]

Did your attacker change lines of attack after put in the curl blocking? 
 Or did the blocking itself not solve the problem?

Here's a thought: use node.js to set up a simple filter (node.js because 
it's high throughput for very lightweight operations).  For valid traffic, 
proxy to your real GAE site, otherwise proxy to a honeypot that will 
black-hole the attacker's requests.  I say proxy rather than redirect so 
that your GAE site can whitelist the IP of your filter - I think HTTP 
referrer can be spoofed, which would defeat the purpose.

Writing node.js proxies is pretty straightforward (there's code for it on 
the net) so the real trick is then making sure you can distinguish attacks 
from normal traffic - hence my original question.

This is all off the top of my head, there may be holes in this plan I 
hadn't thought of.  But it seems like it could work.

- Kris

On Wednesday, August 8, 2012 8:12:17 PM UTC-7, Kate wrote:
>
> My site has been on GAE for several years but am now experiencing denial 
> of service attacks. I don't want to pay for them so my site is now down. I 
> put in a production issue last week and have tried blocking the user agent 
> (curl). But I can't block by IP as all IPs are different.
>
> Apart from moving from GAE what can  I do.
>
> Thanks in advance,
>
> Kate
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/CxhoHfsyxBcJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Low hitting site experiencing denial of service attack - site opffline!

[Kristopher Giesing]

PS.  I think it would also be possible to hide the identity of the GAE app 
the filter talks to.  That way you can move your GAE app to a different app 
ID, so that the attacker can't hit it directly without going through your 
filter.  DNS would also point to your filter.

On Wednesday, August 8, 2012 9:45:51 PM UTC-7, Kristopher Giesing wrote:
>
> Did your attacker change lines of attack after put in the curl blocking? 
>  Or did the blocking itself not solve the problem?
>
> Here's a thought: use node.js to set up a simple filter (node.js because 
> it's high throughput for very lightweight operations).  For valid traffic, 
> proxy to your real GAE site, otherwise proxy to a honeypot that will 
> black-hole the attacker's requests.  I say proxy rather than redirect so 
> that your GAE site can whitelist the IP of your filter - I think HTTP 
> referrer can be spoofed, which would defeat the purpose.
>
> Writing node.js proxies is pretty straightforward (there's code for it on 
> the net) so the real trick is then making sure you can distinguish attacks 
> from normal traffic - hence my original question.
>
> This is all off the top of my head, there may be holes in this plan I 
> hadn't thought of.  But it seems like it could work.
>
> - Kris
>
> On Wednesday, August 8, 2012 8:12:17 PM UTC-7, Kate wrote:
>>
>> My site has been on GAE for several years but am now experiencing denial 
>> of service attacks. I don't want to pay for them so my site is now down. I 
>> put in a production issue last week and have tried blocking the user agent 
>> (curl). But I can't block by IP as all IPs are different.
>>
>> Apart from moving from GAE what can  I do.
>>
>> Thanks in advance,
>>
>> Kate
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/hSS-h1t9MhQJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Low hitting site experiencing denial of service attack - site opffline!

[Kristopher Giesing]

PPS. The point of doing this outside GAE is so that you can run the filter 
on a fixed cost VM solution like Linode.  Then the only question becomes 
whether your attacker can overwhelm your node.js filter... hopefully, it 
won't reach that point.

- Kris

On Wednesday, August 8, 2012 9:48:00 PM UTC-7, Kristopher Giesing wrote:
>
> PS.  I think it would also be possible to hide the identity of the GAE app 
> the filter talks to.  That way you can move your GAE app to a different app 
> ID, so that the attacker can't hit it directly without going through your 
> filter.  DNS would also point to your filter.
>
> On Wednesday, August 8, 2012 9:45:51 PM UTC-7, Kristopher Giesing wrote:
>>
>> Did your attacker change lines of attack after put in the curl blocking? 
>>  Or did the blocking itself not solve the problem?
>>
>> Here's a thought: use node.js to set up a simple filter (node.js because 
>> it's high throughput for very lightweight operations).  For valid traffic, 
>> proxy to your real GAE site, otherwise proxy to a honeypot that will 
>> black-hole the attacker's requests.  I say proxy rather than redirect so 
>> that your GAE site can whitelist the IP of your filter - I think HTTP 
>> referrer can be spoofed, which would defeat the purpose.
>>
>> Writing node.js proxies is pretty straightforward (there's code for it on 
>> the net) so the real trick is then making sure you can distinguish attacks 
>> from normal traffic - hence my original question.
>>
>> This is all off the top of my head, there may be holes in this plan I 
>> hadn't thought of.  But it seems like it could work.
>>
>> - Kris
>>
>> On Wednesday, August 8, 2012 8:12:17 PM UTC-7, Kate wrote:
>>>
>>> My site has been on GAE for several years but am now experiencing denial 
>>> of service attacks. I don't want to pay for them so my site is now down. I 
>>> put in a production issue last week and have tried blocking the user agent 
>>> (curl). But I can't block by IP as all IPs are different.
>>>
>>> Apart from moving from GAE what can  I do.
>>>
>>> Thanks in advance,
>>>
>>> Kate
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/BdA06H3rXigJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: 1.7.1 Pre-release SDKs Available

[Kristopher Giesing]

Until this issue is fixed, I'm stuck on 1.6.3:

http://code.google.com/p/googleappengine/issues/detail?id=7282

- Kris

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/07SidfPu2EcJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: The Data Collection for Game Question

[Kristopher Giesing]

I think the only client implementation for the channel API is the 
JavaScript one.  I'd love to be wrong though.

If there is a way to set up a Java (or Python or Go) client for the channel 
APIs, you would end up with semi-persistent http connections between 
channel service and backend.  I don't know what that would do to the rest 
of the backend's processing, but it could hardly be worse than paying for 
nine extra backend instances...

- Kris

On Wednesday, August 8, 2012 10:47:09 AM UTC-7, Brandon Wirtz wrote:
>
> I don’t have time to build a solution write now, because we are too close 
> to our own product launch, but in thinking about this I wondered about 
> Channel API between servers….
>
>  
>
> This is a solution I have been thinking about and if someone knows why it 
> won’t work that might save me some headache or might reduce theirs if it 
> works.
>
>  
>
> Could you not have frontends use the channel API to send the data to the 
> backend.  The data would be streamed to the backend and the buffer in the 
> channel would allow the backend to read the stream of data in to its 
> memory. The calculations could be done, and then written to datastore and 
> memcache so that when the client re-polled the scores would be correct and 
> shared?
>
>  
>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/YeQXS6tNPfQJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Backend performance, compared

[Kristopher Giesing]

Do we know for sure that front ends are any faster?  Their individual 
throughput limits might just be masked by having more of them spin up.

- Kris

I really don't know why backends are slow.  Maybe it has something to 
> do with the request queueing system?  Throughput sucks even when 
> backends are doing noops.  Maybe "increased concurrency" would allow 
> more requests to travel through the queueing system at once... but 
> it's hard to imagine this helping out the actual server process at 
> all.  More timeslicing and synchronization on a cpu- and memory-bound 
> problem will reduce performance, not improve it. 
>
> Jeff 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/o0pnDf-xnpwJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: 1.7.1 Pre-release SDKs Available

[Kristopher Giesing]

There are no RPC calls - this is computation bound.  So I don't think 
appstats will help (and it doesn't run on the dev server anyway, since I 
switched to backends).  I load a complex model, run some analysis, and then 
save out the model again, but the slowdown I saw was just in the analysis 
part, not the I/O.  (Timing numbers are in a comment in the log - I'm 
seeing around a 30x-40x slowdown on processing time.)

Am I really the only one encountering this?  I can file a new issue if so. 
 Maybe it's specific to the version of the Java VM I happen to have 
installed.

- Kris

On Wednesday, August 8, 2012 10:10:09 PM UTC-7, Takashi Matsuo (Google) 
wrote:
>
> Hi Kristopher, 
>
> On Thu, Aug 9, 2012 at 1:56 PM, Kristopher Giesing 
> > wrote: 
> > Until this issue is fixed, I'm stuck on 1.6.3: 
> > 
> > http://code.google.com/p/googleappengine/issues/detail?id=7282 
>
> Can you provide a reproducible test case or more detailed information 
> for this problem? Otherwise, I don't think we can help. 
> Also, can you file a new issue? 
>
> Probably you can enable appstats on the devserver for tracking each rpc 
> calls. 
>
> Thanks, 
>
> -- Takashi 
>
> > 
> > - Kris 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Google App Engine" group. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msg/google-appengine/-/07SidfPu2EcJ. 
> > 
> > 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 | Developer Advocate | tma...@google.com  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/oKRMN8FzbAwJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Low hitting site experiencing denial of service attack - site opffline!

[Kristopher Giesing]

There's a short example of a node.js proxy server here:

http://www.catonmat.net/http-proxy-in-nodejs/

It might not be as hard as you imagine to get this working.  I'd hate to 
see the attackers win :(

- Kris

On Wednesday, August 8, 2012 10:06:45 PM UTC-7, Kate wrote:
>
> I don't know how to write the node.js. I am surprised that google cannot 
> help me here. I do appreciate your help but I just can't do this without 
> spending hours of study. To answer your other question, the blocking 
> attempt didn't solve the problem. The curl requests come about 3 times per 
>  second. I have been working on trying to stop them for over a week now. I 
> suppose I can just change my domain name or move to another hosting service 
> but it seems a pity.
>
> I have had this site since 1996 with never a problem. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/2ysufh4yO-UJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Backend performance, compared

[Kristopher Giesing]

The reason I'm currently using them is to avoid insane instancing behavior 
on front ends.  (Which is sad, because I'm basically paying extra to avoid 
a feature.)

I just commented on your SO post, btw, asking clarification on whether your 
rules are only for backends, because I definitely *don't* see that behavior 
for front ends.

- Kris

On Wednesday, August 8, 2012 11:21:48 PM UTC-7, Jeff Schnitzer wrote:
>
> On Wed, Aug 8, 2012 at 10:05 PM, vlad > 
> wrote: 
> > Because I thought that all 3 methods that did not work involved storing 
> data 
> > in Datastore. If you used Backend RAM as storage, well, ok it is an 
> > inventive way to use Backend, I guess. I think Backends are a wrong 
> feature 
> > all together. I just does not with GAE  concept as a scalable, 
> > no-configuration system. But I guess we have ourselves to blame. Some of 
> us 
> > screamed so much about 60 sec time limit in front-ends. And this time 
> Google 
> > decided to "listen" and gave us Backends :) 
>
> Only one of the 3 failed attempts used the datastore; the others were 
> task queue and single-backend. 
>
> I also think that backends are a misfeature, but for different reasons: 
>
>  * As an in-memory index, they are waaay too expensive for any 
> reasonable quantity of RAM. 
>  * As a repository of in-game state (ie this case), they don't provide 
> enough throughput. 
>  * As a way around the 60s timeout for frontends... I'd really just 
> rather have the ability to run frontend requests longer.  And to 
> define groups of frontends of different sizes. 
>
> As Google Compute Engine rolls out, I expect the appeal of backends 
> will diminish considerably.  Which is too bad, because if they were 
> cheaper and faster they would be really incredibly useful. 
>
> Jeff 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/Ln4L5qG42d4J.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Backend performance, compared

[Kristopher Giesing]

That would work up until your data got evicted at the wrong time...

Though this gets me thinking: it would be really, really nice for many 
applications to have a *guaranteed* memcached-style in-memory table that 
you could use to share data between instances (and between FE/BE).  Unlike 
memcached there would be no automatic management; instead you would 
manually add/remove items to stay within a hard limit (or put()s would 
fail).  The hard limit could depend on configuration and maybe you could 
pay for more if you needed it.

- Kris

On Thursday, August 9, 2012 7:38:40 AM UTC-7, Hernan Liendo wrote:
>
> *
> On the other hand, I think you could simplify a little your scoring 
> solution. What if you hold user’s scores on sharded MemCache entries and 
> after a while you get all of them and save the result on the DataStore?*
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/3V5Fp6ul8dsJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Backend performance, compared

[Kristopher Giesing]

Good point.  I had unconsciously assumed that a replicated memcached 
solution would be much more efficient than a replicated data store 
solution, but if the replication and not the disk I/O is what's expensive, 
then that assumption falls down.

Generally speaking, I'm having difficulty architecting my own app in such a 
way that it's robust across instances that may be "very distant" from one 
another.  Right now I'm relying on optimistic concurrency in the datastore, 
but it means my app is much slower than, say, a single instance that held 
everything in RAM.  It's been tempting to just drop the datastore entirely 
and limit myself to a single instance, but GAE doesn't seem designed to 
scale down that way; front end instances spin up apparently for no reason, 
and back end instances, as this thread reveals, seem to have more 
performance limitations than one would expect, so I have no idea whether a 
single instance would actually be able to service my user base.

- Kris

On Friday, August 10, 2012 2:30:35 AM UTC-7, Joakim wrote:
>
> By *guaranteed*, do you mean that this should be kept synchronized across 
> multiple data centers? I ask because in the case of a data center 
> emergency, your app spins up at a different data center. The HR datastore 
> is always in sync, the memcache is always local to the DC.
> Comparing the put-latency of the datastore and memcache for the last few 
> days, the datastore generally keeps under 50 ms while memcache tends to 
> stay below 30 ms. I'd say the datastore isn't so bad, and adding sync to 
> memcache would probably bring that number up a bit. At that point, this new 
> feature is starting to look a bit like the current HR datastore. Add 
> properties for insertion date/time etc, and it could be a queue, right?
>
> I don't mean to shoot you down, but to make you specify what it really is 
> you want, and how it relates to the current offering.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/z6MbQajkRboJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: How to blacklist planet-lab.org?

[Kristopher Giesing]

I sympathize with your situation, but how many more threads on this do you 
need?  It's actually harder to help you if the answers to your questions 
are so spread out; people are going to forget what has been proposed and 
tried already.

I still think the most likely solution is for you to have a filtering proxy 
server in front of GAE that has a fixed cost, so that GAE doesn't bill you 
for the DDOS requests.  If CloudFlare doesn't work then I think a simple 
node.js proxy would do the trick, and you could probably host it on a VM 
somewhere for around $10-15 a month.  If you're not prepared to write that 
proxy yourself, you could probably hire someone to do it; the hourly rate 
might be high, but I doubt it would take an experienced developer very long 
at all to do.  I'm tempted to do it myself but I have other obligations 
that would get in the way.

- Kris

On Friday, August 10, 2012 1:01:33 PM UTC-7, Kate wrote:
>
> I have posted about my site being bombarded by curl requests from hundreds 
> of ip addresses in some other threads here and received a lot of help.
>
> It seems that most of the offenders are affiliated with planet-lab and 
> possibly the attacks are mistakes. However as a result my site is being 
> brought down for several hourse per day. I have contacted planet-lab by 
> email with no luck,
>
> I cannot have more that100 subnet entries in my block file on gae, and 
> short of paying more $$$ to google to support these unwanted curl requests 
> I. Can think of nothing else to do.
>
> Can anyone think of how I can get planet-lab to stop?
>  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/KJ3Fmsjp6kQJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Weird Instance Scheduler

[Kristopher Giesing]

Hi Takashi,

I ran some experiments with an instance that had requests pending only from 
my own scripts (no user facing traffic at all).

What I found was that sending requests at about 1req/sec, regularly spaced, 
caused GAE to spin up new instances randomly.  If I set the min instances 
setting to anything but "automatic", the very first request would cause a 
new instance to spin up (this was true even if the min instances was some 
high number, like 8, and I waited for all 8 instances to finish launching 
before sending a request - so in this case the # of instances started at 9 
for the very first request).

The only solution I found for this behavior was to package the entire app 
as a backend.

- Kris

On Friday, August 24, 2012 11:43:23 AM UTC-7, Takashi Matsuo (Google) wrote:
>
>
> Hi Mos,
>
> On Sat, Aug 25, 2012 at 1:39 AM, Mos  >wrote:
>
>> Hello Takashi,
>>
>>
>> > Actually there were almost 8 requests in a second. So App Engine likely 
>> needed more than one instance at this particular moment.
>>
>> I thought this is why GAE has the concept of "pending-latency"  (which we 
>> discussed below).
>> Meaning:  Incoming requests may wait up to 15 seconds before starting a 
>> new instance. Therefore when 8 requests in one second occur that
>> should not mean that more instance needs to be started. Especially if 
>> there is no other traffic in this minute, as seen in my example.
>> Otherwise it would be a very bad implementation:
>> Starting a new instance means around 30s waiting time.  Serving 8 
>> parallel requests from one instance, would result in a maximum of
>> 8 seconds for the last request (assuming that each request takes around 1 
>> second).
>> There is no reason for this concrete example to fire up more instances 
>> and let requests wait more then 30 seconds until a new instance is loaded.
>>
>
> Do you really read my e-mail?
>
> Setting Max Pending Latency doesn't force requests to be in the pending 
> queue for the specified time. Please use Min Pending Latency instead.
> Can you try this first? If it doesn't work, try 2 min idle instances then.
>  
>
>>
>> > ... here is what you've seen in the past weeks.
>> >
>> >* You have been almost always set 'Automatic-2' idle instance setting.
>> >* More than 3 weeks ago, number of loading requests were very few.
>> > * Recently you have seen more loading requests than before.
>>
>> That, right!  To be even more concrete: At the 16. august the problems 
>> got significant worse. Please check especially the time area from 16. 
>> august until today. 
>>
>> > First of all, it seems that you deployed 2 new versions on Aug 1 and 
>> Aug 2. Can you describe what kind of changes in those versions?
>>
>> I checked it in our version control. As I wrote no related changes were 
>> made! Just Html/Css stuff:
>>  * One picture upload
>>  * One html change
>>  * One JavaScript change
>>  * One css change
>>
>>
>> > And, to be fair, we didn't think of any change in our scheduler around 
>> 3 weeks ago which can cause this issue.
>>
>> And around the 16th august?  
>
>
> Sigh... isn't it a waist of time? What is the reason you picked that date? 
>  
>
>>  
>
>
>> > More than 3 weeks before, those 2 idle instances might have had longer 
>> lives than now, but it was not a concrete behavior. Please think this way: 
>> you were just kind of lucky. 
>>
>> That shouldn't be luck! If GAE is not able to start Java instances in 
>> 5sec to 10 second, there needs be a guarantee that instances have longer 
>> lives.  Otherwise Java applications on GAE are unusable because user would 
>> have a lot of 30seconds wait time  (--> "failed requests"). (See also next 
>> comment regarding resistant instances)
>>
>>
>> > If you want some instances always active, please set min idle instances.
>>
>> I tried this some days ago. I had one resistant instance. But that 
>> changed nothing.  Instances get started and stopped as before. I assumed 
>> that requests would go to the resistant instance first. But that was no the 
>> case. Resistant instance was idle, but a dynamic instance got started and 
>> the request waits 30sec.   
>
> Please check other discussion on this list and issues that reported 
>> similar observations. 
>>
>
> So I'd say please try 2. If you still saw the user-facing loading 
> requests, you need more resident instance to eliminate the user-facing 
> loading requests.
>  
>
>>  
>> > As you can see, I'm still not convinced to believe that the scheduler 
>> is misbehaving. I understand that you're having experiences which are bit 
>> worse than 3 weeks ago, and understand your feeling that you want to tell 
>> us 'fix it', but I'd say it's > >still something in the line of 'expected 
>> behavior' at least for now.
>> > If you feel differently, please let me know.
>>
>> Yes I do feel differently (please see answers above). 
>>
>> Please accept 
>> http://code.google.com/p/googleappengine/issues/detail?id=8004
>>
>
> So what is your expected behavior a

Re: [google-appengine] Weird Instance Scheduler

[Kristopher Giesing]

On Friday, August 24, 2012 2:59:11 PM UTC-7, Johan Euphrosine (Google) 
wrote:
>
>
> On Aug 24, 2012 11:28 PM, "Mos" > 
> wrote:
> >
> > Thanks Johan. I read the post some days before.
> >
> > As often discussed on the mailing-list before and as Jeff said in this 
> thread.
> > It's the combination of "Requests should never be sent to cold 
> instances." 
>
> Please star this existing feature request:
> http://code.google.com/p/googleappengine/issues/detail?id=7865
>
Done.
 

> > and(!) the behavior of min idle instance which doesn't make any sense.
>
> Like Jon explained in the post I linked, the scheduler will favor routing 
> traffic to idle dynamic instance rather than idle reserved idle instance 
> and it will always try to maintain the invariant of N x Min-Idle-Instances 
> by starting new instance if the reserved instances are busy.
>
OK, the post by Jon was an interesting read because it explains why Google 
seems to think everything is working as intended.  What doesn't seem to be 
penetrating is that it doesn't matter what some definition on a piece of 
paper somewhere says the system is supposed to do, if that definition 
doesn't actually help developers build good products.

The feature starred above absolutely needs to be implemented.  I just wish 
there was an easier way of getting customers who are frustrated by the 
instancing behavior to focus on that one feature request, because the naive 
interpretation of the existing GAE tuning parameters suggests it shouldn't 
be necessary.

- Kris

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/w3m3ZmnH18cJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Weird Instance Scheduler

[Kristopher Giesing]

>
> Like Jon explained in the post I linked, the scheduler will favor routing 
>> traffic to idle dynamic instance rather than idle reserved idle instance 
>> and it will always try to maintain the invariant of N x Min-Idle-Instances 
>> by starting new instance if the reserved instances are busy.
>>
> PS. The behavior described above is not really the problem IMHO, the 
problem is that the scheduler favors routing traffic to NONEXISTENT dynamic 
instances rather than idle reserved instances.  No one seems to understand 
why that would ever be a good idea.

- Kris

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/y6iVMtCCPKgJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Weird Instance Scheduler

[Kristopher Giesing]

Hi Takashi,

I created a new GAE app to test this and found that I'm not getting the 
same instance tuning controls in the new app ID that I am getting in my 
current one.

In my current app, I can set both min and max idle instances, and min and 
max pending latency.

In the new app, I can set only max idle instances, and min pending latency.

Any ideas why this would be the case?  It complicates the process of 
setting up a good testbed for this.

- Kris

On Friday, August 24, 2012 7:59:17 PM UTC-7, Takashi Matsuo (Google) wrote:
>
> On Sat, Aug 25, 2012 at 5:24 AM, Mos  >wrote:
>
>>  > Setting Max Pending Latency doesn't force requests to be in the 
>> pending queue for the specified time. Please use Min Pending Latency 
>> instead.
>>
>> As you know my setting to "Min Pending Latency" was automatic. The 
>> expectation is that GAE takes a reasonable default latency if it is 
>> "automatic".
>> And you say:  Every parallel request starts a new instance if it is 
>> "automatic"? That' would be a "Min Pending Latency" of zero and not 
>> "automatic".
>>
>> > If it doesn't work, try 2 min idle instances then
>>
>> Please check the responses of other user in this thread.  This feature is 
>> totally broken and can not be used.
>
>
>>
>> >> And around the 16th august?  
>>  > Sigh... isn't it a waist of time? What is the reason you picked that 
>> date? 
>>
>> Did you see/studied my pictures from the first post of this thread?
>> The statistic shows that on this date the instance creation gets crazy.  
>> I double checked it with the Pingdom reports.
>> Starting on this day there were even more downtimes.
>>
>> > So I'd say please try 2. If you still saw the user-facing loading 
>> requests, you need more resident instance to eliminate the user-facing 
>> loading requests.
>>
>> Again: As wrote in my post before that does not work. Check the responses 
>> from Kristopher and Jeff on this thread.
>>
>>
> Yeah, it's very nice to hear concrete examples from Kristopher and Jeff, 
> other than just saying "I've tried that, but it didn't work".
>  
>
>>
>> > So what is your expected behavior and actual result? Nobody in our 
>> team can do anything if you just keep saying "the setting that used to work 
>> doesn't work anymore" without trying mu suggestion.
>> > I think my answer is clear at least for some points. 1) You'd better 
>> use 'min pending latency' instead of 'max pending latency' to prevent new 
>> instances to spin up as much as possible. 2) If you need longer instance 
>> lives, set appropriate number of min idle instances.
>>
>> As I wrote: I tried different settings. As many other people in this 
>> group as well.
>> Me and other people are reporting: The settings are broken!
>> It's very easy to reproduce. Please set up an application, send one 
>> request per minute (or second), configure 1 or 2 or 3 min idle instances 
>> and check what is happening. You will see that new  instances are started 
>> although resistant instances are available.
>>
>
> It's nice if we have a complete reproducible case. I've just started an 
> experiment you mentioned. This time, it's just a helloworld application, 
> and I set 1 min idle instances and 1 minutes cron.
>
> Presumably it will just work fine. Then I will try with slightly different 
> condition. That way, I hope I can determine what kind of condition could be 
> the culprit or not. What do you think? Can you provide some simple projects 
> for that experiment?
>
>
>> Please take it serious and let somebody of the engineers check this!
>>
>
> (I'm one of the engineers btw) A reproducible case is always the best 
> thing to get engineers' attention.
>
> Regards,
>
> -- Takashi
>
>
>> Cheers
>> Mos 
>>
>>
>> On Fri, Aug 24, 2012 at 8:43 PM, Takashi Matsuo 
>> 
>> > wrote:
>>
>>>
>>> Hi Mos,
>>>
>>> On Sat, Aug 25, 2012 at 1:39 AM, Mos 
>>> > wrote:
>>>
 Hello Takashi,


 > Actually there were almost 8 requests in a second. So App Engine 
 likely needed more than one instance at this particular moment.

 I thought this is why GAE has the concept of "pending-latency"  (which 
 we discussed below).
 Meaning:  Incoming requests may wait up to 15 seconds before starting a 
 new instance. Therefore when 8 requests in one second occur that
 should not mean that more instance needs to be started. Especially if 
 there is no other traffic in this minute, as seen in my example.
 Otherwise it would be a very bad implementation:
 Starting a new instance means around 30s waiting time.  Serving 8 
 parallel requests from one instance, would result in a maximum of
 8 seconds for the last request (assuming that each request takes around 
 1 second).
 There is no reason for this concrete example to fire up more instances 
 and let requests wait more then 30 seconds until a new instance is loaded.

>>>
>>> Do you really read my e-mail?
>>>  
>>> Setting Max Pending Latency doesn't force requests

Re: [google-appengine] Re: Weird Instance Scheduler

[Kristopher Giesing]

>
> Resident instances are used for processing incoming request if there 
> is no dynamic instance
>

This is the behavior we all want, but experimentation seems to indicate it 
doesn't happen, at least for some apps.

- Kris

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/_wh1KzpESLEJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Weird Instance Scheduler

[Kristopher Giesing]

I posted a great deal of information in the thread here:

https://groups.google.com/forum/?fromgroups=#!topic/google-appengine/rjZhjMEAXUI

In that thread I posted logs that showed that the very first request after 
setting min instances to 1 will spawn a new instance (in addition to the 
instance that the min instances setting created).  The app ID used in that 
testing is "titan-game-qa" and the timestamps are in the logs I posted.

At some point I will have enough bandwidth to set up a more specific test, 
but I feel I've already posted plenty of information for GAE engineers to 
digest.

- Kris

On Monday, August 27, 2012 2:17:47 AM UTC-7, Johan Euphrosine (Google) 
wrote:
>
> On Mon, Aug 27, 2012 at 7:17 AM, Kristopher Giesing 
> > wrote: 
> >> Resident instances are used for processing incoming request if there 
> >> is no dynamic instance 
> > 
> > 
> > This is the behavior we all want, but experimentation seems to indicate 
> it 
> > doesn't happen, at least for some apps. 
>
> Hi Kristopher, 
>
> Can you comment with the appid and timestamps of when this last happened? 
>
> Thanks in advance. 
>
> > 
> > - Kris 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Google App Engine" group. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msg/google-appengine/-/_wh1KzpESLEJ. 
> > 
> > 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. 
>
>
>
> -- 
> Johan Euphrosine (proppy) 
> Developer Programs Engineer 
> Google Developer Relations 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/ubhrxTXYlC4J.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Weird Instance Scheduler

[Kristopher Giesing]

This is the request that I actually issued, being handled:

2012-07-31 23:08:28.045 /api/game/57002?pretty=true 200 7893ms 11kb 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
like Gecko) Version/6.0 Safari/536.25
76.102.149.245 - kris [31/Jul/2012:23:08:28 -0700] "GET 
/api/game/57002?pretty=true HTTP/1.1" 200 11652 - "Mozilla/5.0 (Macintosh; 
Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, like Gecko) Version/6.0 
Safari/536.25" "titan-game-qa.appspot.com" ms=7893 cpu_ms=3520 api_cpu_ms=0 
cpm_usd=0.099322 instance=00c61b117c77507e2cfe78a0806d0ca80b52720e

These are the *two* preceding warmup requests:

** Dynamic instance warmup **
2012-07-31 23:08:27.475 /_ah/warmup 200 5873ms 0kb
0.1.0.3 - - [31/Jul/2012:23:08:27 -0700] "GET /_ah/warmup HTTP/1.1" 200 60 
- - "1.360723738856412175.titan-game-qa.appspot.com" ms=5873 cpu_ms=2475 
api_cpu_ms=0 cpm_usd=0.068778 loading_request=1 
instance=00c61b117cdaae6145945d99c16aeee7cc0f4ad8

** Resident/idle instance warmup **
2012-07-31 23:07:42.842 /_ah/warmup 200 5045ms 0kb
0.1.0.3 - - [31/Jul/2012:23:07:42 -0700] "GET /_ah/warmup HTTP/1.1" 200 60 
- - "1.360723738856412175.titan-game-qa.appspot.com" ms=5046 cpu_ms=2475 
api_cpu_ms=0 cpm_usd=0.068778 loading_request=1 
instance=00c61b117c77507e2cfe78a0806d0ca80b52720e

This is my point.  The problem is not that a new instance was spawned 
(although I admit that I did not quite understand the desired behavior when 
I first posted this data).  The problem is that the request I issued is not 
satisfied until AFTER the warmup request has been issued and handled by the 
new instance.  The request should FIRST have been handled by the already 
resident instance, AND THEN the new instance should have been spawned.

If I'm misunderstanding something, please clarify, because at the face of 
it this seems to be a smoking gun.

- Kris

On Friday, August 31, 2012 8:37:47 AM UTC-7, Takashi Matsuo (Google) wrote:
>
> On Fri, Aug 31, 2012 at 10:48 AM, Kristopher Giesing 
> 
> > wrote:
>
>> I posted a great deal of information in the thread here:
>>
>>
>> https://groups.google.com/forum/?fromgroups=#!topic/google-appengine/rjZhjMEAXUI
>>
>> In that thread I posted logs that showed that the very first request 
>> after setting min instances to 1 will spawn a new instance (in addition to 
>> the instance that the min instances setting created).  The app ID used in 
>> that testing is "titan-game-qa" and the timestamps are in the logs I posted.
>>
>
> As far as I can see, all of the loading requests in the logs are warmup 
> requests(sorry if I misread the logs). This is very likely an expected 
> behavior. If your resident instance get a request, and if the request is 
> CPU intensive, our scheduler needs to spin up a new instance by sending a 
> warmup request in order to keep the number of idle instance. This will help 
> absorbing subsequent traffic, and this behavior is definitely what the 
> resident instances are for.
>  
>
>>
>> At some point I will have enough bandwidth to set up a more specific 
>> test, but I feel I've already posted plenty of information for GAE 
>> engineers to digest.
>>
>
> Yeah, if you can file an issue with that information, that will definitely 
> help. However, please keep in mind the expected behavior I mentioned above, 
> and add your expected behavior in detail(don't say just 'It didn't work') 
> alongside the things you actually observe.
>
> Thanks,
>
> -- Takashi
>  
>
>>
>> - Kris
>>
>> On Monday, August 27, 2012 2:17:47 AM UTC-7, Johan Euphrosine (Google) 
>> wrote:
>>
>>> On Mon, Aug 27, 2012 at 7:17 AM, Kristopher Giesing 
>>>  wrote: 
>>> >> Resident instances are used for processing incoming request if there 
>>> >> is no dynamic instance 
>>> > 
>>> > 
>>> > This is the behavior we all want, but experimentation seems to 
>>> indicate it 
>>> > doesn't happen, at least for some apps. 
>>>
>>> Hi Kristopher, 
>>>
>>> Can you comment with the appid and timestamps of when this last 
>>> happened? 
>>>
>>> Thanks in advance. 
>>>
>>> > 
>>> > - Kris 
>>> > 
>>> > -- 
>>> > You received this message because you are subscribed to the Google 
>>> Groups 
>>> > "Google App Engine" group. 
>>> > To view this discussion on the web visit 
>>> > https://groups.google.com/d/**msg/google-appengine/-/_**wh1KzpESLEJ<https://groups.google.com/d/msg/google-appengine/-/

Re: [google-appengine] Re: Weird Instance Scheduler

[Kristopher Giesing]

OK. Something just became clearer to me.

The requests appear to be tagged with the instance that handles the 
request.  Based on that data, it looks like my request is in fact being 
handled by the resident instance, not the new dynamic instance.

The puzzle then becomes why the request still takes 8s to satisfy when the 
instance handling it is already warmed, and the in-application logging code 
(which I didn't post, but trust me on this) is never higher than about 
400ms.  I had been assuming that the 8s cost was the cost of the new 
instance spinning up, but the instance tag seems to contradict that.

The answer has to be some kind of static initialization cost.  Although my 
app is not very complex, I wonder if this is due to the class path scanning 
that JDO does.  I have since switched to Objectify, but I am actually not 
very clear on whether that is sufficient to prevent JDO/JPA class path 
scanning; it seems like I would need to evict the JDO/JPA core code from my 
application on deployment, but it's far from clear to me how to do that.

... But even that may not really explain this behavior because you would 
think static initialization costs would be born by the warmup request.

So, actually, I am baffled.  Any ideas, anyone?

- Kris

On Friday, August 31, 2012 9:16:16 PM UTC-7, Kristopher Giesing wrote:
>
> This is the request that I actually issued, being handled:
>
> 2012-07-31 23:08:28.045 /api/game/57002?pretty=true 200 7893ms 11kb 
> Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, 
> like Gecko) Version/6.0 Safari/536.25
> 76.102.149.245 - kris [31/Jul/2012:23:08:28 -0700] "GET 
> /api/game/57002?pretty=true HTTP/1.1" 200 11652 - "Mozilla/5.0 (Macintosh; 
> Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, like Gecko) Version/6.0 
> Safari/536.25" "titan-game-qa.appspot.com" ms=7893 cpu_ms=3520 
> api_cpu_ms=0 cpm_usd=0.099322 
> instance=00c61b117c77507e2cfe78a0806d0ca80b52720e
>
> These are the *two* preceding warmup requests:
>
> ** Dynamic instance warmup **
> 2012-07-31 23:08:27.475 /_ah/warmup 200 5873ms 0kb
> 0.1.0.3 - - [31/Jul/2012:23:08:27 -0700] "GET /_ah/warmup HTTP/1.1" 200 60 
> - - "1.360723738856412175.titan-game-qa.appspot.com" ms=5873 cpu_ms=2475 
> api_cpu_ms=0 cpm_usd=0.068778 loading_request=1 
> instance=00c61b117cdaae6145945d99c16aeee7cc0f4ad8
>
> ** Resident/idle instance warmup **
> 2012-07-31 23:07:42.842 /_ah/warmup 200 5045ms 0kb
> 0.1.0.3 - - [31/Jul/2012:23:07:42 -0700] "GET /_ah/warmup HTTP/1.1" 200 60 
> - - "1.360723738856412175.titan-game-qa.appspot.com" ms=5046 cpu_ms=2475 
> api_cpu_ms=0 cpm_usd=0.068778 loading_request=1 
> instance=00c61b117c77507e2cfe78a0806d0ca80b52720e
>
> This is my point.  The problem is not that a new instance was spawned 
> (although I admit that I did not quite understand the desired behavior when 
> I first posted this data).  The problem is that the request I issued is not 
> satisfied until AFTER the warmup request has been issued and handled by the 
> new instance.  The request should FIRST have been handled by the already 
> resident instance, AND THEN the new instance should have been spawned.
>
> If I'm misunderstanding something, please clarify, because at the face of 
> it this seems to be a smoking gun.
>
> - Kris
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/4FGx8YdHUIgJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Channel API not working in production

[Kristopher Giesing]

On Friday, August 31, 2012 12:29:20 PM UTC-7, Pascal Patry wrote:
>
> Hi, 
>
> Channels on AppEngine are picky. There are multiple issues that I had to 
> work around for an application that is currently in production: 
> 1. Channels aren't working on backends 
>

Argh, seriously? That is a huge problem for me :(
 

> 2. No API is available to mobile
>

I worked around this by embedding the jsapi code in my application.  It 
seems to work fine... so far.
 

> 3. The implementation is different from the test and production server
>

Yes, that is a pain.  I had to add a wrapper class to my application to 
choose between embedded test and prod implementations dynamically.
 

> 4. Connection/Disconnection handlers aren't reliably called 
>

Are you talking about this? If so it was fixed: 
http://code.google.com/p/googleappengine/issues/detail?id=7098

The fix isn't public yet but there's a patch in the thread.

- Kris

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/0hvmO28CXcAJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Protocol Buffers

[Kristopher Giesing]

I thought protocol buffers were designed to minimize bandwidth, not 
latency?  I don't see how a data transmission format would minimize latency.

I've never had any serious problems with JSON, personally.

- Kris

On Friday, August 31, 2012 8:57:14 AM UTC-7, Brandon Wirtz wrote:
>
> We haven’t had much luck with the ProtoRPC on Python 2.7 Like hello world 
> is a pain to get up, and it is really poorly documented.
>
>  
>
> *From:* google-a...@googlegroups.com  [mailto:
> google-a...@googlegroups.com ] *On Behalf Of *Larry White
> *Sent:* Friday, August 31, 2012 4:54 AM
> *To:* google-a...@googlegroups.com 
> *Subject:* [google-appengine] Protocol Buffers
>
>  
>
> is there any support in appengine for using protocol buffers for data 
> transfer (eg. through RPCs).  
>
>  
>
> If not, what recommended practices do people have for minimizing latency 
> between AppEngine and clients, when clients are spread across the globe?
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Google App Engine" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/google-appengine/-/-7T-KWknCvEJ.
> 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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/YXgWWLa19x8J.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Weird Instance Scheduler

[Kristopher Giesing]

The 400ms was measured from the time that the code entered my servlet's get 
method.  I can't be sure anymore since I've rewritten the code since then 
to use Objectify, but I'm guessing that it did not include the first PMF 
construction call.

If constructing the PMF is what was costing a bunch of time, then I'm 
guessing that the warmup request was not constructing one, but that it was 
getting constructed at static init time relative to the actual request.

I'll keep an eye on this once I'm ready to deploy again (the rewrite to 
Objectify came with a bunch of other changes I need to finish before I'm 
ready for real testing again).  For the moment, though, it seems like the 
problems I was having were due to a misunderstanding of how GAE instance 
warmups happen, and not due to a problem with the instance scheduler itself.

- Kris

On Saturday, September 1, 2012 3:57:07 PM UTC-7, Jeff Schnitzer wrote:
>
> Yeah, baffling.  JDO startup costs come with the construction of the 
> PersistenceManagerFactory, so that should be "in your code". 
>
> That 400ms - is that measured from a filter at the outermost layer? 
>
> An interesting thing to try is to set up a handler for the warmup 
> request which issues an actual query to the datastore.  Any query. 
>
> Jeff 
>
> On Fri, Aug 31, 2012 at 9:25 PM, Kristopher Giesing 
> > wrote: 
> > OK. Something just became clearer to me. 
> > 
> > The requests appear to be tagged with the instance that handles the 
> request. 
> > Based on that data, it looks like my request is in fact being handled by 
> the 
> > resident instance, not the new dynamic instance. 
> > 
> > The puzzle then becomes why the request still takes 8s to satisfy when 
> the 
> > instance handling it is already warmed, and the in-application logging 
> code 
> > (which I didn't post, but trust me on this) is never higher than about 
> > 400ms.  I had been assuming that the 8s cost was the cost of the new 
> > instance spinning up, but the instance tag seems to contradict that. 
> > 
> > The answer has to be some kind of static initialization cost.  Although 
> my 
> > app is not very complex, I wonder if this is due to the class path 
> scanning 
> > that JDO does.  I have since switched to Objectify, but I am actually 
> not 
> > very clear on whether that is sufficient to prevent JDO/JPA class path 
> > scanning; it seems like I would need to evict the JDO/JPA core code from 
> my 
> > application on deployment, but it's far from clear to me how to do that. 
> > 
> > ... But even that may not really explain this behavior because you would 
> > think static initialization costs would be born by the warmup request. 
> > 
> > So, actually, I am baffled.  Any ideas, anyone? 
> > 
> > - Kris 
> > 
> > 
> > On Friday, August 31, 2012 9:16:16 PM UTC-7, Kristopher Giesing wrote: 
> >> 
> >> This is the request that I actually issued, being handled: 
> >> 
> >> 2012-07-31 23:08:28.045 /api/game/57002?pretty=true 200 7893ms 11kb 
> >> Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 
> (KHTML, 
> >> like Gecko) Version/6.0 Safari/536.25 
> >> 76.102.149.245 - kris [31/Jul/2012:23:08:28 -0700] "GET 
> >> /api/game/57002?pretty=true HTTP/1.1" 200 11652 - "Mozilla/5.0 
> (Macintosh; 
> >> Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, like Gecko) 
> Version/6.0 
> >> Safari/536.25" "titan-game-qa.appspot.com" ms=7893 cpu_ms=3520 
> api_cpu_ms=0 
> >> cpm_usd=0.099322 instance=00c61b117c77507e2cfe78a0806d0ca80b52720e 
> >> 
> >> These are the *two* preceding warmup requests: 
> >> 
> >> ** Dynamic instance warmup ** 
> >> 2012-07-31 23:08:27.475 /_ah/warmup 200 5873ms 0kb 
> >> 0.1.0.3 - - [31/Jul/2012:23:08:27 -0700] "GET /_ah/warmup HTTP/1.1" 200 
> 60 
> >> - - "1.360723738856412175.titan-game-qa.appspot.com" ms=5873 
> cpu_ms=2475 
> >> api_cpu_ms=0 cpm_usd=0.068778 loading_request=1 
> >> instance=00c61b117cdaae6145945d99c16aeee7cc0f4ad8 
> >> 
> >> ** Resident/idle instance warmup ** 
> >> 2012-07-31 23:07:42.842 /_ah/warmup 200 5045ms 0kb 
> >> 0.1.0.3 - - [31/Jul/2012:23:07:42 -0700] "GET /_ah/warmup HTTP/1.1" 200 
> 60 
> >> - - "1.360723738856412175.titan-game-qa.appspot.com" ms=5046 
> cpu_ms=2475 
> >> api_cpu_ms=0 cpm_usd=0.068778 loading_request=1 
> >> instance=00c61b117c77507e2cfe78a0806d0ca80b52720e 
> >> 
> >> This is my point.  

Re: [google-appengine] Channel API not working in production

[Kristopher Giesing]

I thought the Channel API was already based on web sockets (for platforms 
that support them).

- Kris

On Sunday, September 2, 2012 3:31:31 PM UTC-7, vlad wrote:
>
> +1  Channels is probably the most overhyped but underwhelming feature on 
> GAE. It was launched with lots of hype and high expectations. Still after 2 
> years to is mostly unusable. GAE team is better off killing Channels as a 
> feature to free up resources and focus on delivering websockets.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/4NVg2Md-uHoJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Channel API not working in production

[Kristopher Giesing]

>
> > 3. The implementation is different from the test and production server 
>
> Care to elaborate? (file new Defect if necessary) 
>

It's pretty clear to anyone working with the system more than casually that 
the implementations are different.  I'm not sure that's really a problem; I 
mean, the whole dev server is different from the production server. 
 There's only so much you can mimic from a distributed hosting environment 
locally.

What *is* a problem is when the behaviors differ subtly from dev to prod. 
 For example, if the dev server guarantees (even if accidentally) event 
ordering in one way, when in prod the event ordering isn't guaranteed, 
that's a problem.  I'm not familiar enough with channels in prod to know 
what might fall into that category, but I've seen very similar effects in 
other systems.

- Kris 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/sWGHjjWHdNkJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] how to use the goole app engine as backend for the iphone application

[Kristopher Giesing]

Actually this is such an open ended question that I think it's not 
particularly suited to SO.

Shilendra,

Generally speaking, you should be able to use GAE as a back end for an 
iPhone application.  I'm aiming to do this and although I have not yet 
deployed my app I've learned quite a bit about what does and doesn't work 
well.  There are some things to be aware of before going in.

- You'll probably want a different authentication mechanism than GAE gives 
you by default (unless you truly want your APIs to be public).  What I did 
was embed an application ID in my iPhone app, then check for it on the GAE 
side before returning responses.  I use HTTPS to avoid the application ID 
being sniffable on the network.
- The Channel APIs won't be available to you unless you are running an 
HTML5 application (e.g. through PhoneGap).  This is because the only client 
implementation for Channels is the JavaScript one.

There are also some things you should know that aren't specific to the 
client:

- Because of the distributed nature of GAE, you have no raw access to the 
file system, and no guarantees about the lifetime of in-memory structures. 
 You have the data store and memcached instead.  GAE strongly encourages 
stateless architectures.
- The GAE data store isn't a traditional database, and trying to treat it 
like one (e.g. by using JDO/JPA for your persistence framework) causes lots 
of headaches.  I'd recommend starting with Objectify instead, which was 
designed explicitly for GAE.
- The development environment is great, and very convenient... but in many 
ways it doesn't (and probably can't) mimic the behaviors of the production 
environment.  Design your app so you can test on an actual GAE deployment 
before your end users see it.

- Kris

On Monday, September 3, 2012 2:14:32 AM UTC-7, Johan Euphrosine (Google) 
wrote:
>
> HI Shilendra, 
>
> That would be a better question for stack overflow: 
> http://stackoverflow.com/questions/tagged/google-app-engine 
>
> On Mon, Sep 3, 2012 at 6:30 AM, Shilendra Sharma 
> > 
> wrote: 
> > Hi everyone 
> > 
> > I have an iPhone application and want to use the Google app engine 
> services( 
> > datastore , Google cloud storage and more ) as back end for iPhone 
> > application , so how it possible please guide me or suggest me, 
> > 
> > App Shilendra 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Google App Engine" group. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msg/google-appengine/-/3ngby-R0HBYJ. 
> > 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. 
>
>
>
> -- 
> Johan Euphrosine (proppy) 
> Developer Programs Engineer 
> Google Developer Relations 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/PO_pPMH34vYJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: How do I stop all the duplicate posting copies to the LinkedIn "Google App Engine Developers" group?

[Kristopher Giesing]

My guess is your LinkedIn group is getting the email digests from this 
group.  I can think of a few ways this might happen:

1) Someone signed up to this Google group with the email address by which 
people can directly post to your LinkedIn group
2) Someone has an automatic forwarding rule for the digests to go to the 
email address by which people can directly post to your LinkedIn group

My guess would be 2), but that means the problem is out of this group's 
control.  If you peek at the headers for the spammy posts, can you tell 
what user they were posted on behalf of?

On Wednesday, September 19, 2012 11:23:20 AM UTC-7, Greg wrote:
>
> We periodically get a blast of at least 6 identical postings from this 
> blog to the LinkedIn "Google App Engine Developers group".  I only recently 
> started moderating this LinkedIn group, and I have no idea how those posts 
> even get there, or how to stop or specify them.  Who is causing this, and 
> how can we reduce this to just one posting?   We're making a serious effort 
> to eliminate spam in this group, and posting an item more than once 
> effectively makes it spam! 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/elbsCxSaknwJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Weird Instance Scheduler

[Kristopher Giesing]

OK, ready to deploy again, and of course I immediately ran into this issue 
(along with a bunch of problems related to channels).

Here are the logs.  Note the 7-second gap between the request that created 
a new instance, and the immediately preceding instance.  Note also that 
there was no warmup request.  I now see in the documentation that warmup 
requests aren't guaranteed, so I'm not sure adding a warmup handler will 
actually help me; in any case, I haven't explicitly disabled them.

So, yeah.  No solution at this point, and random 10s delays are not 
acceptable. Takashi, can you analyze this and tell me what's going on?


   1. 
  1. 2012-09-21 01:50:03.465 
  
/api/game/80001/submit?messages=MOVE+Gray.Cross+600+136+135+134+2+false;MOVE+Gray.Queue+600+34+35+36+0+false&index=21
  200 176ms 0kb Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) 
  AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206
  
  76.102.149.245 - - [21/Sep/2012:01:50:03 -0700] "POST 
/api/game/80001/submit?messages=MOVE+Gray.Cross+600+136+135+134+2+false;MOVE+Gray.Queue+600+34+35+36+0+false&index=21
 HTTP/1.1" 200 192 - "Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) 
AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206" 
"titan-game-qa.appspot.com" ms=176 cpu_ms=163 cpm_usd=0.80 
instance=00c61b117c15f0ab71ada0d4f932c37adf981007 

  
  2. 
  1. 2012-09-21 01:49:50.460 
  
/api/game/80001/submit?messages=SPLIT+Gray.Queue+Gray.Cross+Angel+Centaur+Centaur+Gargoyle&index=17
  200 9609ms 0kb Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) 
  AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206
  
  76.102.149.245 - - [21/Sep/2012:01:49:50 -0700] "POST 
/api/game/80001/submit?messages=SPLIT+Gray.Queue+Gray.Cross+Angel+Centaur+Centaur+Gargoyle&index=17
 HTTP/1.1" 200 187 - "Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) 
AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206" 
"titan-game-qa.appspot.com" ms=9609 cpu_ms=5063 cpm_usd=0.80 
loading_request=1 instance=00c61b117cf26825e763cc7957e0c35cc39d68 

  
  2. I2012-09-21 01:49:50.460 This request caused a new process to be 
  started for your application, and thus caused your application code to be 
  loaded for the first time. This requ
   3. 
  1. 2012-09-21 01:49:33.240 
  /api/game/80001/submit?messages=MARKERCHOICE+Black.Horn&index=14200 
  459ms 0kb Mozilla/5.0 (iPad; CPU OS 5_0_1 like Mac OS X) 
  AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9A405
  
  76.102.149.245 - - [21/Sep/2012:01:49:33 -0700] "POST 
/api/game/80001/submit?messages=MARKERCHOICE+Black.Horn&index=14 HTTP/1.1" 200 
136 - "Mozilla/5.0 (iPad; CPU OS 5_0_1 like Mac OS X) AppleWebKit/534.46 
(KHTML, like Gecko) Mobile/9A405" "titan-game-qa.appspot.com" ms=459 cpu_ms=187 
cpm_usd=0.74 instance=00c61b117c15f0ab71ada0d4f932c37adf981007 

  
  4. 
  1. 2012-09-21 01:49:31.124 
  /api/game/80001/submit?messages=COLORCHOICE+Black&index=11200 244ms 
  0kb Mozilla/5.0 (iPad; CPU OS 5_0_1 like Mac OS X) AppleWebKit/534.46 
  (KHTML, like Gecko) Mobile/9A405
  
  76.102.149.245 - - [21/Sep/2012:01:49:31 -0700] "POST 
/api/game/80001/submit?messages=COLORCHOICE+Black&index=11 HTTP/1.1" 200 129 - 
"Mozilla/5.0 (iPad; CPU OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like 
Gecko) Mobile/9A405" "titan-game-qa.appspot.com" ms=244 cpu_ms=210 
cpm_usd=0.73 instance=00c61b117c15f0ab71ada0d4f932c37adf981007 

  
  

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/bruR2wS3IGoJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Weird Instance Scheduler

[Kristopher Giesing]

PS.  This is with default application settings, and for this test I 
reverted to using front ends instead of backends (since I gather backends 
don't support channels, that's no longer an option for me).

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/-1SggFlu3_sJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] App Engine HRD migration and easier process for people with no data

[Kristopher Giesing]

Google's messaging about migration is getting stronger, so I assume the 
"why bother" is "so Google doesn't one day shut down my instance".

- Kris

On Thursday, September 20, 2012 4:30:07 PM UTC-7, Joshua Smith wrote:
>
> I have one such app, and I can tell you that it has had exactly 0 downtime 
> for years. If you don't use the datastore, then whether you are on HR or 
> M/S completely doesn't matter. Even during periodic maintenance, the app 
> will just keep on serving.
>
> So… why bother?
>
> On Sep 20, 2012, at 5:09 PM, Greg Linden > 
> wrote:
>
> Perhaps I'm wrong, but I'd assume there are a large number of appengine 
> applications that have stored nothing in the datastore.
>
> It would be fantastic if there was a quick, easy tool to do the migration 
> to HRD for those applications without the hassle of changing the 
> application name and other goodies people with a more serious migrations 
> have to do.  Again, I may be wrong, but I'd assume that, if you have no 
> data in your master/slave datastore, if you are not using your master/slave 
> datastore, the migration to HRD could be done in place.
>
> Perhaps someone at Google could think about that, whether it would be easy 
> to do, and how many people fall into this category.  I'm sure you'd have 
> much higher compliance if you made it easier, and this probably is one easy 
> way to make it easier for a large number of people.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Google App Engine" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/google-appengine/-/VpNv04_Nr1YJ.
> 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.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/4TM_AH3o8JkJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: How do I stop all the duplicate posting copies to the LinkedIn "Google App Engine Developers" group?

[Kristopher Giesing]

I think you need to ask someone who knows how content makes it into that 
section of the LinkedIn group (such as LinkedIn support).  There is surely 
some kind of audit trail or spammers would just be able to blast the groups 
with noise.  I'm not sure anyone on this group will be able to help you.

- Kris

On Thursday, September 20, 2012 1:09:01 PM UTC-7, Greg wrote:
>
> To clarify, the LInkedIn posts are linking to blog entries from the 
> official "Google App Engine Blog", not digests from this forum.  For 
> instance, one of those blog postings is at
> http://googleappengine.blogspot.com/2012/09/app-engine-172-released.html 
>
> You can see the copied-in postings on the "discussions" for that LinkedIn 
> group (since it's an open group), at 
> http://www.linkedin.com/groups?gid=128878 
>
> I apologize for posting here, but I didn't see another place to do it.  It 
> didn't seem appropriate to add a comment to the original blog entries, 
> since the problem is not specific to each blog entry.  In that blog 
> posting, it said to provide "general discussion and feedback", find "us" 
> (meaning the authors of that blog) at this forum, providing a link to it.   
> So I'm hoping that the Google people who generate the blog postings are 
> indeed watching this forum.   The blog is "the official Google App Engine 
> Blog", so I'm assuming someone at Google set this up. 
>
> There's no headers to look at, since this doesn't involve e-mail.  The 
> entry just appears on the web page for "discussions" (the second link 
> provided above). 
>
>
>
> On Wednesday, September 19, 2012 1:23:20 PM UTC-5, Greg wrote:
>>
>> We periodically get a blast of at least 6 identical postings from this 
>> blog to the LinkedIn "Google App Engine Developers group".  I only recently 
>> started moderating this LinkedIn group, and I have no idea how those posts 
>> even get there, or how to stop or specify them.  Who is causing this, and 
>> how can we reduce this to just one posting?   We're making a serious effort 
>> to eliminate spam in this group, and posting an item more than once 
>> effectively makes it spam! 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/MtwSwLEpbjEJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: using app engine for extremely demanding multiplayer browser game

[Kristopher Giesing]

Reads can be cached through the memcached service, and memcached hits are 
free.

If you try GAE, I would highly recommend re-examining your architecture to 
make optimal use of GAE's strengths.  I haven't released my own app yet, 
but when I started I tried to use JDO, and the performance was awful. 
 After switching to Objectify not only did my performance improve 
significantly, but nearly all the database reads disappeared due to the 
ease with which Objectify integrates with memcached.

- Kris

On Tuesday, September 13, 2011 4:03:10 AM UTC-7, Karel Crombecq wrote:
>
> Hey Jay,
>
> I did some calculations on my current database data, and CQ2 generates 
> about 1M database writes for something like 650 daily users. That's about 3 
> times as much as your game does, which would also triple the bill. That's a 
> lot, but something I can handle. Since most of the writes are one-record 
> only, the total cost would be $1,5 per day for 1000 users.
>
> However, the datastore reads are the real issue here. I have about 4M 
> SELECT queries for 650 users. Considering that many of these return more 
> than one row, I can easily reach 10M datastore reads each day, for an 
> additional cost of $2,8 each day.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/wPcLsjyzPIQJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Weird Instance Scheduler

[Kristopher Giesing]

To be clear, my problem isn't with startup time per se.  My problem is that 
despite having an active instance that has been idle for 7 seconds, GAE 
decided to spin up a new instance, causing a significant user-visible delay.

Secondarily, I'm puzzled as to why I didn't get a warmup request, but as I 
mentioned, the docs explicitly state that warmup requests aren't 
guaranteed, so perhaps that is expected.

- Kris

On Wednesday, September 26, 2012 1:09:14 AM UTC-7, Rekby wrote:
>
> I have same problem with startup delay 
> http://stackoverflow.com/q/12581110/1204368 
>
> PS.  This is with default application settings, and for this test I 
> reverted to using front ends instead of backends (since I gather backends 
> don't support channels, that's no longer an option for me). 
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Google App Engine" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/google-appengine/-/-1SggFlu3_sJ.
> 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.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/cQkV48uND7oJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Scheduler still not working as expected.

[Kristopher Giesing]

On Saturday, October 13, 2012 5:31:43 AM UTC-7, Takashi Matsuo (Google) 
wrote:

>
> In a very rare case, App Engine sometimes needs to direct a request to 
> another instance(even if there is an idle instance) for some reasons. I 
> think this is a nature of a distributed and shared system like App Engine.
>

I'm speechless.

Does GAE have an SLA or not?  If so, what is it?

I'm really starting to regret boarding this train.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/rn5oHn4uUswJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Scheduler can be a real mystery...

[Kristopher Giesing]

"Almost all"?

Can you please just tell us what the bug was?

- Kris

On Saturday, October 13, 2012 2:56:31 AM UTC-7, Takashi Matsuo (Google) 
wrote:
>
> Hi Jason,
>
> Thanks for the info. I think I found the edge case bug on your app(and 
> which doesn't affect almost all of other apps). I've escalated it to the 
> reliability team.
>
> I think you can manually shut down some of your instances for a temporary 
> measure.
>
> Sorry for the inconvenience.
>
> -- Takashi
>
>
> On Sat, Oct 13, 2012 at 3:07 PM, Jason Collins 
> 
> > wrote:
>
>> We do use the Datastore Admin backup via cron, but it's not scheduled to 
>> start for another 3 hours.
>>
>> App ID: repcore-prod
>>
>>
>> On Friday, 12 October 2012 23:44:57 UTC-6, Takashi Matsuo (Google) wrote:
>>
>>> Hi Jason,
>>>
>>> I assume the answer is no, but just in case, do you have any 
>>> backup/delete job with the datastore admin?
>>> Can you tell me your app-id, so I'll take a look?
>>>
>>> -- Takashi
>>>
>>>
>>> On Sat, Oct 13, 2012 at 2:35 PM, Jason Collins wrote:
>>>
 See attached. Almost zero "active", but 7 instances being billed. Using 
 F4's, Python 2.7, threadsafe: true. Idle Instances set to 1-Automatic.


 
 Surely the scheduler can do better than this? Can anyone explain this?

  -- 
 You received this message because you are subscribed to the Google 
 Groups "Google App Engine" group.
 To view this discussion on the web visit https://groups.google.com/d/**
 msg/google-appengine/-/**KOVJvCuDdBEJ
 .
 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 | Developers Advocate | tma...@google.com
>>>
>>>   -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Google App Engine" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/google-appengine/-/22Qlx5IFM7kJ.
>>
>> 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 | Developers Advocate | tma...@google.com 
>
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/hP9n1FootD0J.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: The instance manager/scheduler spins up 4 additional instances to serve a request stream from a single browser session

[Kristopher Giesing]

When I looked into this recently, I discovered that GAE was actually 
sending the new request to the guaranteed idle instance, but then also 
spinning up another instance at the same time, making it seem as if the 
request were being handled by the cold instance.  The 2nd instance spinning 
up is working as intended; GAE is guaranteeing an idle instance, and the 
current warm instance is handling a request.

On Wednesday, October 17, 2012 1:35:31 PM UTC-7, Jason Collins wrote:
>
> The most pathological case is when you ask for 1 Min Idle Instance (so 
> that you get warmup requests), but if that instance is actually idle, the 
> scheduler sends the request to a new cold instance instead of allowing the 
> warm one that's sitting there to handle it.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/q1ILeclrUaYJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Issues with Channel connection status

[Kristopher Giesing]

I'm in what should be the final stages of development prior to deploying my 
app.  But I can't figure out how to use the Channel API effectively.

What I need out of the system is a way to notify a user of certain events. 
 If the user is connected by a channel, I use that, but if they aren't, I 
want to send a push notification.  That means I need some way of telling 
whether or not a user is connected.

I should be able to use the connected/disconnected API calls for this, but 
I can't tell that they are reliable enough.  After struggling with 
mysterious failures to send messages, I started just logging every connect 
and disconnect message for each user, at the moment my app receives the 
calls.

I've enclosed a session (below the sig since it's long) with the token 
timeout set to 1 minute.  This is not a production value, but I'm setting 
it that way to test whether a user's session will survive intact when the 
token does time out.  So what I should see below is an initial connect, 
followed by a disconnect/connect pair every minute.  What I get instead is 
a seemingly completely random scattering.  The only explanation I can come 
up with for the lack of a pattern below is that there is a highly variable 
latency for connect and disconnect calls, a latency so high that it 
completely obscures what should be a per-minute pattern.

Is there any way to tell reliably whether a message sent on a channel 
either will be received or has been received?  I think what I really want 
is async http semantics, like the async URL Fetch service provides, but 
ChannelService.sendMessage returns void.

Thanks,

- Kris

"2012-10-19 05:14:41.074: CONNECT"
"2012-10-19 05:14:51.975: DISCONNECT"
"2012-10-19 05:14:59.005: CONNECT"
"2012-10-19 05:16:02.244: CONNECT"
"2012-10-19 05:16:32.312: DISCONNECT"
"2012-10-19 05:17:06.129: CONNECT"
"2012-10-19 05:17:37.564: DISCONNECT"
"2012-10-19 05:18:10.850: CONNECT"
"2012-10-19 05:18:43.400: DISCONNECT"
"2012-10-19 05:19:15.571: CONNECT"
"2012-10-19 05:20:02.696: DISCONNECT"
"2012-10-19 05:20:20.306: CONNECT"
"2012-10-19 05:21:18.098: DISCONNECT"
"2012-10-19 05:21:24.552: CONNECT"
"2012-10-19 05:21:54.450: DISCONNECT"
"2012-10-19 05:22:28.524: CONNECT"
"2012-10-19 05:22:58.342: DISCONNECT"
"2012-10-19 05:23:35.089: CONNECT"
"2012-10-19 05:24:05.763: DISCONNECT"
"2012-10-19 05:24:41.071: CONNECT"
"2012-10-19 05:25:11.415: DISCONNECT"
"2012-10-19 05:25:46.249: CONNECT"
"2012-10-19 05:26:17.876: DISCONNECT"
"2012-10-19 05:26:51.309: CONNECT"
"2012-10-19 05:27:21.467: DISCONNECT"
"2012-10-19 05:27:56.865: CONNECT"
"2012-10-19 05:28:26.661: DISCONNECT"
"2012-10-19 05:29:01.161: CONNECT"
"2012-10-19 05:29:30.979: DISCONNECT"
"2012-10-19 05:30:06.248: CONNECT"
"2012-10-19 05:30:09.558: DISCONNECT"
"2012-10-19 05:30:36.361: DISCONNECT"
"2012-10-19 05:54:38.777: CONNECT"
"2012-10-19 05:54:58.359: DISCONNECT"
"2012-10-19 05:55:02.256: CONNECT"
"2012-10-19 05:56:05.113: CONNECT"
"2012-10-19 05:56:43.411: DISCONNECT"
"2012-10-19 05:57:08.320: CONNECT"
"2012-10-19 05:57:38.325: DISCONNECT"
"2012-10-19 05:58:12.434: CONNECT"
"2012-10-19 05:58:42.443: DISCONNECT"
"2012-10-19 05:59:16.679: CONNECT"
"2012-10-19 05:59:46.686: DISCONNECT"
"2012-10-19 06:00:21.892: CONNECT"
"2012-10-19 06:01:06.169: DISCONNECT"
"2012-10-19 06:01:25.725: CONNECT"
"2012-10-19 06:02:09.637: DISCONNECT"
"2012-10-19 06:02:32.373: CONNECT"
"2012-10-19 06:03:03.003: DISCONNECT"
"2012-10-19 06:03:37.183: CONNECT"
"2012-10-19 06:04:14.422: DISCONNECT"
"2012-10-19 06:04:44.372: CONNECT"
"2012-10-19 06:05:15.403: DISCONNECT"
"2012-10-19 06:05:52.034: CONNECT"
"2012-10-19 06:06:27.457: DISCONNECT"
"2012-10-19 06:06:59.136: CONNECT"
"2012-10-19 06:07:56.649: DISCONNECT"
"2012-10-19 06:08:04.653: CONNECT"
"2012-10-19 06:09:03.384: DISCONNECT"
"2012-10-19 06:09:09.987: CONNECT"
"2012-10-19 06:09:54.077: DISCONNECT"
"2012-10-19 06:10:09.552: DISCONNECT"
"2012-10-19 06:10:15.505: CONNECT"
"2012-10-19 06:10:30.732: DISCONNECT"
"2012-10-19 06:10:44.468: CONNECT"
"2012-10-19 06:11:50.181: CONNECT"
"2012-10-19 06:12:20.296: DISCONNECT"
"2012-10-19 06:12:55.736: CONNECT"
"2012-10-19 06:13:25.753: DISCONNECT"
"2012-10-19 06:14:04.029: CONNECT"
"2012-10-19 06:15:02.722: DISCONNECT"
"2012-10-19 06:15:13.511: CONNECT"
"2012-10-19 06:15:43.393: DISCONNECT"
"2012-10-19 06:16:16.961: CONNECT"
"2012-10-19 06:16:46.845: DISCONNECT"
"2012-10-19 06:17:21.435: CONNECT"
"2012-10-19 06:17:51.345: DISCONNECT"
"2012-10-19 06:18:25.748: CONNECT"
"2012-10-19 06:18:57.003: DISCONNECT"
"2012-10-19 06:19:33.036: CONNECT"
"2012-10-19 06:20:07.889: DISCONNECT"
"2012-10-19 06:20:38.335: CONNECT"
"2012-10-19 06:21:21.366: DISCONNECT"
"2012-10-19 06:21:42.598: CONNECT"
"2012-10-19 06:22:12.590: DISCONNECT"
"2012-10-19 06:22:50.721: CONNECT"
"2012-10-19 06:23:20.663: DISCONNECT"
"2012-10-19 06:23:55.112: CONNECT"
"2012-10-19 06:24:51.063: DISCONNECT"
"2012-10-19 06:24:59.041: CONNECT"
"2012-10-19 06:25:57.816: DISCONNECT"
"2012-10-19 06:26:04.661: CONNECT"
"2012-

Re: [google-appengine] No warmup requests are being issued by the Java instance scheduler

[Kristopher Giesing]

On Monday, October 22, 2012 5:51:38 AM UTC-7, Takashi Matsuo (Google) wrote:
>
>
> Hi Carl,
>
> On Mon, Oct 22, 2012 at 8:26 AM, Carl Schroeder 
> 
> > wrote:
>
>> Has this feature been disabled? Have the requirements for it changed?
>> The "Configured Services" section of my Application Settings says that 
>> "Warmup Requests" are enabled.
>> I can find no trace of any warmup requests in my logs.
>>
>
> Currently, the warmup requests are issued only when you have some min idle 
> instances settings instead of 'automatic'.
>

This isn't mentioned in the documentation anywhere that I can see.  Did I 
miss it?  It seems like an incredibly important point to leave out.
 

>
>> Also, the scheduler is still acting crazy. It is starting up new java 
>> instances (with user facing requests) when there are dynamic instances 
>> alive and well and idle. 20 second response times to REST calls that 
>> normally return in 50ms is simply unacceptable performance. Asking my users 
>> to wait 40 seconds while a page that contains multiple REST calls loads is 
>> simply not an option.
>>
>
> To avoid this, currently the options are
> * to have sufficient number of min idle instances
> or
> * to make your loading requests faster
>

The third option, of course, is to use something other than GAE.  Given 
that solution #1 pushes GAE costs over paying for an always-on host from 
another vendor, and #2 doesn't get you to a reasonable SLA, #3 honestly 
looks like the best choice from where I'm sitting.

I'm trying very hard not to get angry about this.  I actually have a good 
friend who is a developer on App Engine and I want very much to make this 
work, but it just seems like the scheduler is fundamentally broken, and 
Google is refusing to recognize it.  Am I missing something?  For those of 
you who have apps deployed on GAE, why isn't this behavior killing you?

- Kris
 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/_a7nB5IG5u0J.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: No warmup requests are being issued by the Java instance scheduler

[Kristopher Giesing]

Can you post the relevant logs?  Each request is stamped with the ID of the 
instance that served it.

When I looked into my own logs I found that the request I thought was 
cold-served was actually going to a recently warmed instance, but that the 
warmup request didn't fully initialize everything so the first request 
after warmup was still too long.  But it sounds like you have more and 
better data here to prove something is actually broken.

- Kris

On Monday, October 22, 2012 11:07:11 AM UTC-7, Carl Schroeder wrote:
>
> I just tested with my Application Settings configured to have 1 Resident 
> instance.
>
> With 1 resident, and 1 idle instance. I hit a page reload. 7 requests were 
> served by the instances according to the Instances pane in the App Engine 
> Console. The requests were handled in the following manner:
> Zero went to the Resident instance. 
> 3 new instances were spun up. 2 with warmup requests, 1 with the first 
> user request given to a cold start.
> 4 then went to the existing idle dynamic instance
> 1 of the new instances handled 3 requests, the other 2 only handled 
> warmups.
>
> The VERY first request (the basic HTML of the page) went to a cold 
> instance. This happened despite the fact that there was an idle Resident 
> instance available AND an idle Dynamic instance available. The user 
> experience is staring at the browser for 20 seconds before anything 
> happens. That is unacceptable.
>
> Even with 4 dynamic instances, the scheduler is still spinning up new ones 
> with user facing requests. This is bizarre, pathological, diabolical, 
> nonsensical behavior. I am running out of adjectives here.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/fVxm5TjouXsJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: No warmup requests are being issued by the Java instance scheduler

[Kristopher Giesing]

I'm not asking you to prove it to yourself or me, but to Google :)

- Kris

On Monday, October 22, 2012 3:17:44 PM UTC-7, Carl Schroeder wrote:
>
> It is actually pretty easy to prove when a request is going to a cold 
> instance vs a warmed up one. Simply output a log line from a place that is 
> only called during initialization of an instance. Make sure that the warmup 
> handler calls this part of the code, and that the code is only called once 
> per instance. I put mine in the abstraction layer that sits between 
> appengine, and my application code. 
>
> My warmup handler shows this log message. So does any user facing request 
> that causes an instance of my app to be initialized.
>
> Also, I did a search for "This request caused a new process" in the log 
> files. Just today, 27 instance starts. My app can serve its user base off a 
> single instance with excellent response times. (If only I had a way to tell 
> the scheduler to piss off)
>
> For the past hour, I had 3 warmups handled and 4 user facing requests 
> routed to cold instances. I verified that the instances spun up by user 
> facing requests had different IDs than the ones spun up by warmup reqeusts. 
> I have an AWS instance that hits my site once every 60s to attempt to 
> insure that there is always a dynamic instance loaded. I have 1 resident 
> instance configured to "enable" warmups.
>
>
> On Monday, October 22, 2012 2:55:19 PM UTC-7, Kristopher Giesing wrote:
>>
>> Can you post the relevant logs?  Each request is stamped with the ID of 
>> the instance that served it.
>>
>> When I looked into my own logs I found that the request I thought was 
>> cold-served was actually going to a recently warmed instance, but that the 
>> warmup request didn't fully initialize everything so the first request 
>> after warmup was still too long.  But it sounds like you have more and 
>> better data here to prove something is actually broken.
>>
>> - Kris
>>
>> On Monday, October 22, 2012 11:07:11 AM UTC-7, Carl Schroeder wrote:
>>>
>>> I just tested with my Application Settings configured to have 1 Resident 
>>> instance.
>>>
>>> With 1 resident, and 1 idle instance. I hit a page reload. 7 requests 
>>> were served by the instances according to the Instances pane in the App 
>>> Engine Console. The requests were handled in the following manner:
>>> Zero went to the Resident instance. 
>>> 3 new instances were spun up. 2 with warmup requests, 1 with the first 
>>> user request given to a cold start.
>>> 4 then went to the existing idle dynamic instance
>>> 1 of the new instances handled 3 requests, the other 2 only handled 
>>> warmups.
>>>
>>> The VERY first request (the basic HTML of the page) went to a cold 
>>> instance. This happened despite the fact that there was an idle Resident 
>>> instance available AND an idle Dynamic instance available. The user 
>>> experience is staring at the browser for 20 seconds before anything 
>>> happens. That is unacceptable.
>>>
>>> Even with 4 dynamic instances, the scheduler is still spinning up new 
>>> ones with user facing requests. This is bizarre, pathological, diabolical, 
>>> nonsensical behavior. I am running out of adjectives here.
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/wR97gMq2QmwJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Issues with Channel connection status

[Kristopher Giesing]

Yeah, I already starred that one.

So... what's the solution?  Is there one or do I need to roll my own 
channel replacement?

On Monday, October 22, 2012 12:46:43 PM UTC-7, Aleksei Rovenski wrote:
>
> My experience with presence notifications is also that they are 
> unreliable. 
> Channel API has some problems, you can read this topic for more:
>
> https://groups.google.com/forum/?fromgroups=#!searchin/google-appengine/channel$20unreliable/google-appengine/lqaCMEj8IyQ/7eWTcLqJxWsJ
>
> I have created an issue some time ago re presences problem, please star 
> it. 
> It is as simple as adding a timestamp to presence notification.
> http://code.google.com/p/googleappengine/issues/detail?id=8151
>
> PS Btw for about a month now there is a new problem that working channel 
> stops receiving messages w/o any errors for undefined period of time and 
> then may start receiving them again...
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/yeFYz_SIikYJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] does the channel api work across domains?

[Kristopher Giesing]

The live version uses an embedded iFrame.  The dev server version can't 
work across domains without modifications, but I have gotten it to work by 
adding a method that overrides the base URL.

- Kris

On Monday, October 22, 2012 2:27:28 PM UTC-7, niedbalski wrote:
>
> Hello Chard ...
>
> The big question here is HOW ?
>
> On Friday, December 3, 2010 3:24:30 PM UTC-3, Peter Petrov wrote:
>>
>> You can. The Channel API is designed to workaround 
>> the JavaScript same-origin policy, and will work across domains.
>>
>> On Fri, Dec 3, 2010 at 8:16 PM, Chad Burt  wrote:
>>
>>> Say I have an application hosted outside of appengine. I'd like to build 
>>> a chat app hosted on appengine to take advantage of the channel API. Can I 
>>> use that system from the first app on a different domain? If so, will it 
>>> work on all browsers, or just those that support the crossdomain access 
>>> control header ?
>>> Thanks,
>>> -Chad
>>>
>>> -- 
>>> 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.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/XhrDeAk5WQUJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Channel Service: Allow-origin ( Cross-domain )

[Kristopher Giesing]

It should work cross-domain already.  Why do you need to configure those 
headers?

- Kris

On Monday, October 22, 2012 2:11:27 PM UTC-7, niedbalski wrote:
>
> Hello guys,
>
> Do you know any way or workaround to get the channel service working with 
> cross-domain requests? Is possible
> to configure the following headers??
>
> Access-Control-Allow-Headers,
> 'Access-Control-Allow-Origin', 
>
> Any hint or idea will be appreciated 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/ZadMJmL8y4cJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] does the channel api work across domains?

[Kristopher Giesing]

I added a function like this to the channel javascript:

goog.appengine.DevSocket.setConnectionBase = function(base) { 
goog.appengine.DevSocket.BASE_URL = base + "_ah/channel/"};

...

goog.exportSymbol("goog.appengine.Channel.setConnectionBase", 
goog.appengine.DevSocket.setConnectionBase);

This allowed me to serve the channel javascript as a static file served 
outside of appspot.com instead of through the normal page load process. 
(This is a static mobile app based on PhoneGap.) The base URL I set to was 
the appspot.com domain.

- Kris

On Wednesday, October 24, 2012 2:10:20 PM UTC-7, niedbalski wrote:
>
> Hi Kristopher,
>
> On Tuesday, October 23, 2012 3:15:02 AM UTC-3, Kristopher Giesing wrote:
>
>> The live version uses an embedded iFrame.  The dev server version can't 
>> work across domains without modifications, but I have gotten it to work by 
>> adding a method that overrides the base URL.
>>
>> - Kris
>>
>> On Monday, October 22, 2012 2:27:28 PM UTC-7, niedbalski wrote:
>>>
>>> ...
>>>
>>>
>
> Do you know why the development server is not using the same iframe 
> work-around ?  Can you share your hack for this?
>
> Thanks you.
>
> JNR.
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/J-Jm7wfuwgoJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] does the channel api work across domains?

[Kristopher Giesing]

Sorry, check that, for development I set the connection base to the 
equivalent of localhost.  I also added the same methods to the prod version 
of the channel JS, which was trickier because it's minified.

This works for me because cross domain restrictions don't apply to 
statically served files, at least on iOS devices.  Your use case may be 
different.

- Kris

On Saturday, October 27, 2012 10:48:26 AM UTC-7, Kristopher Giesing wrote:
>
> I added a function like this to the channel javascript:
>
> goog.appengine.DevSocket.setConnectionBase = function(base) { 
> goog.appengine.DevSocket.BASE_URL = base + "_ah/channel/"};
>
> ...
>
> goog.exportSymbol("goog.appengine.Channel.setConnectionBase", 
> goog.appengine.DevSocket.setConnectionBase);
>
> This allowed me to serve the channel javascript as a static file served 
> outside of appspot.com instead of through the normal page load process. 
> (This is a static mobile app based on PhoneGap.) The base URL I set to was 
> the appspot.com domain.
>
> - Kris
>
> On Wednesday, October 24, 2012 2:10:20 PM UTC-7, niedbalski wrote:
>>
>> Hi Kristopher,
>>
>> On Tuesday, October 23, 2012 3:15:02 AM UTC-3, Kristopher Giesing wrote:
>>
>>> The live version uses an embedded iFrame.  The dev server version can't 
>>> work across domains without modifications, but I have gotten it to work by 
>>> adding a method that overrides the base URL.
>>>
>>> - Kris
>>>
>>> On Monday, October 22, 2012 2:27:28 PM UTC-7, niedbalski wrote:
>>>>
>>>> ...
>>>>
>>>>
>>
>> Do you know why the development server is not using the same iframe 
>> work-around ?  Can you share your hack for this?
>>
>> Thanks you.
>>
>> JNR.
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/6aaAEoHCs0EJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] does the channel api work across domains?

[Kristopher Giesing]

As an addendum to this... I am migrating off the channel API.  I did some 
testing today with enough logging in place to prove that the channel API 
was silently failing to deliver messages to connected clients.  Given all 
the other problems, this was the straw that broke the camel's back.

Since I already have a node.js instance standing by to deliver Apple push 
notifications, I'm going to expand that instance's role to handling 
connected message transport as well.  I'm planning to use socket.io to do 
this.  I should be able to do this in such a way that it's largely 
transparent to the client, abstracted behind a class that knows how to 
connect to the messaging service and fan out resulting messages.  If people 
are interested I'll post the solution somewhere when it's done.

- Kris

On Saturday, October 27, 2012 10:52:55 AM UTC-7, Kristopher Giesing wrote:
>
> Sorry, check that, for development I set the connection base to the 
> equivalent of localhost.  I also added the same methods to the prod version 
> of the channel JS, which was trickier because it's minified.
>
> This works for me because cross domain restrictions don't apply to 
> statically served files, at least on iOS devices.  Your use case may be 
> different.
>
> - Kris
>
> On Saturday, October 27, 2012 10:48:26 AM UTC-7, Kristopher Giesing wrote:
>>
>> I added a function like this to the channel javascript:
>>
>> goog.appengine.DevSocket.setConnectionBase = function(base) { 
>> goog.appengine.DevSocket.BASE_URL = base + "_ah/channel/"};
>>
>> ...
>>
>> goog.exportSymbol("goog.appengine.Channel.setConnectionBase", 
>> goog.appengine.DevSocket.setConnectionBase);
>>
>> This allowed me to serve the channel javascript as a static file served 
>> outside of appspot.com instead of through the normal page load process. 
>> (This is a static mobile app based on PhoneGap.) The base URL I set to was 
>> the appspot.com domain.
>>
>> - Kris
>>
>> On Wednesday, October 24, 2012 2:10:20 PM UTC-7, niedbalski wrote:
>>>
>>> Hi Kristopher,
>>>
>>> On Tuesday, October 23, 2012 3:15:02 AM UTC-3, Kristopher Giesing wrote:
>>>
>>>> The live version uses an embedded iFrame.  The dev server version can't 
>>>> work across domains without modifications, but I have gotten it to work by 
>>>> adding a method that overrides the base URL.
>>>>
>>>> - Kris
>>>>
>>>> On Monday, October 22, 2012 2:27:28 PM UTC-7, niedbalski wrote:
>>>>>
>>>>> ...
>>>>>
>>>>>
>>>
>>> Do you know why the development server is not using the same iframe 
>>> work-around ?  Can you share your hack for this?
>>>
>>> Thanks you.
>>>
>>> JNR.
>>>
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/LCFvn7W_PL0J.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Issues with Channel connection status

[Kristopher Giesing]

I'm going to migrate off the channel API and replace it with a hosted 
node.js instance running socket.io.  If people are interested I can post 
the resulting solution somewhere.

- Kris

On Tuesday, October 23, 2012 1:21:58 AM UTC-7, Aleksei Rovenski wrote:
>
> I don't know of any proper solution I'm afraid except to use other service 
> like Pusher maybe. 
> In my app there is a workaround, clients contact server quite often, so 
> when there is a false disconnect server returns them special code.
> If they are actually connected, they simply inform the server that they 
> are and life goes on. Most of the time this happens behind the scenes.
> However this is ugly indeed, when there is a reconnect, there is often a 
> bunch of requests when client and server keep trying to figure out whats 
> going on.
> Actually when I look at my channels code, it is basically covered with all 
> kinds of workarounds like this :(
>
> вторник, 23 октября 2012 г., 9:10:06 UTC+3 пользователь Kristopher Giesing 
> написал:
>>
>> Yeah, I already starred that one.
>>
>> So... what's the solution?  Is there one or do I need to roll my own 
>> channel replacement?
>>
>> On Monday, October 22, 2012 12:46:43 PM UTC-7, Aleksei Rovenski wrote:
>>>
>>> My experience with presence notifications is also that they are 
>>> unreliable. 
>>> Channel API has some problems, you can read this topic for more:
>>>
>>> https://groups.google.com/forum/?fromgroups=#!searchin/google-appengine/channel$20unreliable/google-appengine/lqaCMEj8IyQ/7eWTcLqJxWsJ
>>>
>>> I have created an issue some time ago re presences problem, please star 
>>> it. 
>>> It is as simple as adding a timestamp to presence notification.
>>> http://code.google.com/p/googleappengine/issues/detail?id=8151
>>>
>>> PS Btw for about a month now there is a new problem that working channel 
>>> stops receiving messages w/o any errors for undefined period of time and 
>>> then may start receiving them again...
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/Ti1VGCi7tToJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Update on our GAE Experience

[Kristopher Giesing]

On Wednesday, November 21, 2012 7:49:34 AM UTC-8, Brandon Wirtz wrote:

> I can also assure you it was not a move to CloudFlare. 
>
>
Zing! Not boring.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/AkyliQ577zAJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Update on our GAE Experience

[Kristopher Giesing]

On Friday, November 23, 2012 3:18:22 AM UTC-8, alex wrote:
>
>
> I already imagined you've tried everything up to a point to consider 
> you and your team to be experts in every single subject. I thought I'd 
> waste time in this thread only because I didn't want too many other 
> people consider your original post to be a "public opinion", because 
> things are simply not how you describe them. At least for what 
> concerns the technical part. 
>

I haven't heard a credible refutation of anything Brandon wrote in the 
original post.  My own (admittedly limited) experience is very consistent 
with Brandon's description.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/ms5qOoafgzoJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Issues with Channel connection status

[Kristopher Giesing]

I have an update on plans to migrate off the channel APIs.

I looked at both socket.io and sockjs, and neither one of them turned out 
to be acceptable.  socket.io's error handling has some serious issues, and 
sockjs doesn't pass cookies in the connection request (intentionally - they 
claim it's a security hole if anyone does that, but they're making 
assumptions about cookie handling that in my case aren't true).

So here's where I ended up:

- GAE instance continues as usual, for now
- Node.js instance runs a low-level web socket implementation.  I used 
websocket-node, but ws probably would have worked as well.
- Node.js additionally runs a low-level Apple push notification 
implementation
- On the client, which is a hybrid iOS app, I have a native (Objective-C) 
implementation of the web socket client, called SocketRocket. 
 SocketRocket, like socket.io, has some error handling issues, but there's 
no other real option and I was able to work around them.
- The HTML layer then talks to the native layer over a local-http bridge 
(intercepted using NSURLProtocol subclassing, which is a standard trick 
I've used in a bunch of other places)

I used an Objective-C library rather than the UIWebView implementation of 
WebSocket because I'm supporting older iOS devices that don't have 
WebSocket support. However, this tradeoff means that I don't get 
cross-browser support, since many browsers don't have sufficient support 
for WebSockets to connect to the service (websocket-node only supports the 
latest RFC versions of the WebSocket protocol, not earlier Hybi versions).

It all works pretty well.  I now understand why the connection state works 
the way it does in GAE; there is almost certainly a proxy server somewhere 
in GAE land that's holding the channel connection separate from the GAE app 
itself.  However, given that architecture there are a bunch of things that 
the Channel API failed on, which were pretty trivial to deliver in my 
replacement:

- I can send to multiple clients in one request (fan-out)
- I can send multiple messages in one request (batching)
- I can instantly fall back to Apple push notifications if a client is not 
connected (and the message format is the same, so the application level in 
the client doesn't have to care how the message was delivered)
- The request is synchronous so I get a result status back, with individual 
reporting on each client and each message
-- Note though that the result status isn't bulletproof; it just reports 
connection up/down at the time Node.js issues the socket write.  Since the 
socket write is asynchronous, it won't report errors that happen after 
dispatch.  But it's good enough for my purposes.

Some of the tradeoffs I've made mean that the work I've done isn't 
necessarily applicable to another project.  So I'm not planning to post 
this e.g. to github for now.  However, I wanted to post what I've done in 
case others want to pursue a similar path.  The node.js service is only 
about 100 lines of code; most of the tricky bits had to do with shunting 
events around on the client and providing a proper abstraction for 
SocketRocket's error reporting.

Cheers,

- Kris

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/OLnVuy4jr8IJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Update on our GAE Experience

[Kristopher Giesing]

On Friday, November 23, 2012 11:45:56 PM UTC-8, Jeff Schnitzer wrote:
>
> Hmmm... I was planning to sit this discussion out, but some of this is 
> unfair.
>
> The support-related complaints are certainly legit.  "Never have humans do 
> well what algorithms can do badly" is woven deep into the fabric of Google, 
> no surprise.
>
> The issue list is pretty reasonable.  Stuff does get fixed, but it's a 
> long list.  Please _don't_ close bugs as WontFix unless someone makes an 
> explicit decision not to fix something.  It's unrealistic to expect a 
> roadmap three years out, which is probably how long it would take to fix 
> all the existing issues.
>

Yeah, not buying that one either, really. However - and this is a big "but" 
- it drives me crazy how fast bugs get *introduced* in GAE and then not 
fixed for a long time.  I'm still on 1.6.3 because that's the last release 
that didn't have a crippling (for me) bug.
 

> The edges of GAE need to be treaded upon carefully.  Avoid the email, 
> xmpp, and channel apis.  Avoid backends.  The bread-and-butter apis are 
> pretty effective though:  datastore, task queue, memcache, and urlfetch.
>

Don't forget Objectify over JDO/JPA.  I don't know why Objectify isn't the 
recommended API, other than I guess it's technically not Google's.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/xPlp7p0iBKgJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Sub Thread: Google's Conflicting Objectives.

[Kristopher Giesing]

Two thoughts:

First, GAE's technology doesn't scale down to small projects, and its 
support model doesn't scale up to large ones.  That spells trouble, to me.

Second, I suspect Google is running experiments on GAE.  By this I don't 
just mean playing around with technology; I mean the specific 
experimentation framework and process that they employ for internal 
software components.  Yahoo did the same thing when I was there.  Basically 
it means that rolling out a new implementation of something involves 
rolling it out to 100 people, then 1000, then 10,000, then everyone.  If it 
looks like things are going south you pull the plug.  That works for 
products you own and manage because there are internal feedback mechanisms. 
 When the products are owned and managed by 3rd parties, though, it sucks. 
 Don't experiment with my platform, please.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/JeH1Gqw5YNsJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Is there any open source GAE code for a simple turn based multiplayer engine?

[Kristopher Giesing]

I just released Titan HD for iPad 2.0 with online multiplayer support. 
 This is a turn-based board game.  It uses GAE for most game logic but I 
had to add another server to handle some things GAE couldn't (specifically, 
live connection multiplexing using WebSockets).

I can give you a rundown of what I had to do if you're interested. 
 However, if you're going the browser based route, some of your decisions 
will be different from mine.  For example, not all browsers support 
WebSockets, so you need some kind of compatibility layer like socket.io or 
SockJS (I wouldn't recommend the Channel APIs due to stability).  Also, I 
used Game Center for authentication, rather than OpenID or the like.

- Kris

On Wednesday, December 12, 2012 11:39:43 AM UTC-8, Bryan wrote:
>
> Thinking of making a very simple turn based mobile game for Facebook or 
> Google users.  Is anyone aware of an existing working platform on Google 
> Code I could deploy to my GAE setup?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/eT-kJG8FYpsJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Is there any open source GAE code for a simple turn based multiplayer engine?

[Kristopher Giesing]

PS.  None of what I did is open source and I would probably want to clean a 
lot of stuff up before releasing it, although the thought has crossed my 
mind more than once.

On Thursday, December 13, 2012 11:16:47 AM UTC-8, Kristopher Giesing wrote:
>
> I just released Titan HD for iPad 2.0 with online multiplayer support. 
>  This is a turn-based board game.  It uses GAE for most game logic but I 
> had to add another server to handle some things GAE couldn't (specifically, 
> live connection multiplexing using WebSockets).
>
> I can give you a rundown of what I had to do if you're interested. 
>  However, if you're going the browser based route, some of your decisions 
> will be different from mine.  For example, not all browsers support 
> WebSockets, so you need some kind of compatibility layer like socket.ioor 
> SockJS (I wouldn't recommend the Channel APIs due to stability).  Also, 
> I used Game Center for authentication, rather than OpenID or the like.
>
> - Kris
>
> On Wednesday, December 12, 2012 11:39:43 AM UTC-8, Bryan wrote:
>>
>> Thinking of making a very simple turn based mobile game for Facebook or 
>> Google users.  Is anyone aware of an existing working platform on Google 
>> Code I could deploy to my GAE setup?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/a67xbP7RJ34J.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Sub Thread: Google's Conflicting Objectives.

[Kristopher Giesing]

Issues like this seem to plague low traffic projects much more than high 
traffic ones:

https://groups.google.com/forum/?fromgroups=#!topic/google-appengine/icdr3dcuoew

However, it's possible this is specific to the Java implementation.

On Sunday, November 25, 2012 4:41:19 PM UTC-8, Brandon Thomson wrote:
>
>
> GAE's technology doesn't scale down to small projects
>>
>
> I don't agree with this. I run several small projects on GAE, some for 
> free. There are limitations, but if you work within them it is an excellent 
> platform for small projects.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/bGe5ttKwd0MJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: channel api not working on production

[Kristopher Giesing]

I've seen problems with the Channel API where both sides of the connection 
were "half open", i.e. each side believed there was a connection but 
messages would not be sent.

I eventually replaced the Channel API with a node.js service running 
WebSockets.  The GAE app posts messages to this service using URLFetch.  It 
has worked really well so far, with only one outage incident (which was my 
own fault) and none of the issues with intermittent connectivity that I was 
seeing with Channel.

- Kris

On Sunday, December 30, 2012 12:00:42 PM UTC-8, 0914...@umt.edu.pk wrote:
>
> I've recently faced the problem. I've implemented some collaborative work 
> on my app. I've used the Channel API and it works really fine on localhost. 
> After deploy, the "update" in the other client is never received. why?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/Mnu2Bm-mAPAJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] channel api not working on production

[Kristopher Giesing]

This is exactly my experience.  I would recommend to anyone considering use 
of the Channel APIs that they find an alternative.

- Kris

On Friday, January 4, 2013 12:15:33 AM UTC-8, Aleksei Rovenski wrote:
>
> I can confirm this issue. It is there from August, it was the first time I 
> noticed at least. For us it looks like this - everything connected and 
> works, messages flow, then all of a sudden w/o any pattern in time or any 
> other conditions, client simply stops receiving any messages. No callbacks, 
> nothing. Then after an unspecified time messages may start going through 
> again or may not. Sometimes it doesn't happen for a long time, sometimes it 
> happens very often.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/6LxcCjS5r1EJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Oh, she scales

[Kristopher Giesing]

16s average latency though...

On Monday, January 7, 2013 12:02:55 PM UTC-8, Brandon Wirtz wrote:
>
> We are doing load testing. 
>
>  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/p-7A7ogXZU4J.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: GAE keeps starting new instances causing lots of user facing loading requests

[Kristopher Giesing]

I set up a duplicate app ID for beta testing.  Would that work for you?

- Kris

On Thursday, January 10, 2013 1:33:21 PM UTC-8, Carl Schroeder wrote:
>
> We still have this bug in spades.
>
> We can no longer give access to beta java versions (they are non-default) 
> because they are unusable in low traffic scenarios. This stings the most, 
> since our users can no longer critique any versions except the "default" 
> one.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/R8fdxqpKfVQJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Lots of user-facing loading requests

[Kristopher Giesing]

I'm not sure Google has ever admitted there is a problem to be fixed.

On Thursday, January 31, 2013 11:30:32 AM UTC-8, Michael Hermus wrote:
>
> I have seriously considered moving user facing functionality to a default 
> python version (dynamic web pages and Ajax calls) but the effort would be 
> pretty massive, and I am clinging to hope that they will fix this issue 
> soon. Although its not in the 1.7.5 release :(

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Re: Lots of user-facing loading requests

[Kristopher Giesing]

The behavior is expected, but rewriting in Python or Go may allow cold 
instances to spin up faster, which does alleviate the resulting user impact.

On Thursday, January 31, 2013 12:57:03 PM UTC-8, Igor Kharin wrote:
>
> Hello Mike, 
>
> > If I rewrite the backend from Java to Python (or Go) will this solve the 
> > problem? 
>
> No, since it is expected behaviour. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Lots of user-facing loading requests

[Kristopher Giesing]

On Wednesday, January 23, 2013 1:34:49 PM UTC-8, Francois Masurel wrote:
>
> Only one new instance started over the last hour.
>
> Yesterday, at the same time, it was 2 instance loading requests every 3 
> minutes.
>
> Google definitely fixed something on their side.
>
> Thanx guys.  But please, don't touch anything now :-)
>
> François
>

I don't think Google fixed anything.  I think the behavior is just 
dependent on what else is going on in the data center.

Here is the image of my instance count over the last month.  Notice how, 
about 2.5 weeks ago, the blue line started to be way higher than the green 
line?  That's when GAE gets into its poor behavior state, from what I can 
tell.  Nothing about my app changed at all in this time, including average 
user activity.

The only reason I can live with this behavior is that my cold start time is 
fast enough for the relatively lax latency requirements of my app.  If my 
requirements were different I would be screaming bloody murder.  As it is, 
I don't recommend GAE for small projects under most conditions.

[image: chart.png]
 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Lots of user-facing loading requests

[Kristopher Giesing]

Image didn't come through, here is the url:

http://topped-with-meat.com/~kgiesing/instances.1.31.png

On Thursday, January 31, 2013 1:36:06 PM UTC-8, Kristopher Giesing wrote:
>
> On Wednesday, January 23, 2013 1:34:49 PM UTC-8, Francois Masurel wrote:
>>
>> Only one new instance started over the last hour.
>>
>> Yesterday, at the same time, it was 2 instance loading requests every 3 
>> minutes.
>>
>> Google definitely fixed something on their side.
>>
>> Thanx guys.  But please, don't touch anything now :-)
>>
>> François
>>
>
> I don't think Google fixed anything.  I think the behavior is just 
> dependent on what else is going on in the data center.
>
> Here is the image of my instance count over the last month.  Notice how, 
> about 2.5 weeks ago, the blue line started to be way higher than the green 
> line?  That's when GAE gets into its poor behavior state, from what I can 
> tell.  Nothing about my app changed at all in this time, including average 
> user activity.
>
> The only reason I can live with this behavior is that my cold start time 
> is fast enough for the relatively lax latency requirements of my app.  If 
> my requirements were different I would be screaming bloody murder.  As it 
> is, I don't recommend GAE for small projects under most conditions.
>
> [image: chart.png]
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Re: Lots of user-facing loading requests

[Kristopher Giesing]

I've never been able to validate the algorithm there with my own app.  As 
mentioned in the comments to that answer, I've definitely seen new 
instances spawn when (to the best of my ability to tell) none of the listed 
criteria were true.

Perhaps it would be a good idea if, in the "This request spawned a new 
instance" message, there was an additional note indicating the number of 
other instances that were examined before spawning the new request, along 
with more detailed information on why those other instance weren't deemed 
suitable.  This could get verbose, so perhaps an admin setting could toggle 
it on/off so that it could be turned on temporarily for investigative 
purposes and turned back off later.

- Kris

On Thursday, January 31, 2013 3:14:49 PM UTC-8, Igor Kharin wrote:
>
> Your arguments are absolutely valid, though. Back then we all thought 
> resident instances are just more flexible version of what "Always On" was, 
> but they are not (and that's why engineers were forced to explain it here).
>
> Yes, an instance *might *be able to serve up to 10 concurrent requests, 
> but it's much more complicated. Johan Euphrosine explained it in all the 
> details:
>
> http://stackoverflow.com/questions/11525717/when-does-the-app-engine-scheduler-use-a-new-thread-vs-a-new-instance/11882719#11882719
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: The server encountered an error and could not complete your request.

[Kristopher Giesing]

That typically means your app returned a 500 error code to whatever was 
fetching the document (it's not clear below whether you're running in a 
browser or making an API call from an app or something else).

You should check the admin console for the deployed app and go to the logs 
section.  Any query that returns a 500 should be tagged as an error, so if 
you filter on that you should see the full log for the failed query.  A 500 
is returned in numerous circumstances; one of the more common cases is a 
null pointer exception in your Java code, just to give you an idea.  But 
the log should tell you what happened in any case.

https://developers.google.com/appengine/docs/adminconsole/index

- Kris

On Monday, February 11, 2013 8:02:01 PM UTC-8, inviteef...@gmail.com wrote:
>
> Hi all,
>
> I used JDO to implement a query. Everything is fine in my localhost. But 
> when I deployed my code, it shows:
>
> Error: Server Error
> The server encountered an error and could not complete your request.
> If the problem persists, please report your problem and mention this error 
> message and the query that caused it.
> for the query page.
>
> I didn't get any error in eclipse console, nor warning. And I did exactly 
> as the 
> https://developers.google.com/appengine/docs/java/datastore/jdo/queries
> the page can be fine as long as I do not process the results. What might 
> be wrong? Anyone have any suggestions?
>
> Thanks!
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] threadsafe not working

[Kristopher Giesing]

I always get irritated when people point to that SO article.  There are 
unanswered questions still and my own experimentation didn't bear out the 
algorithm listed there.  It might be relevant that the answer was posted 
relative to the Python implementation, while I have a Java app, but still.

That SO article isn't satisfying as an authoritative answer.

- Kris

On Tuesday, February 26, 2013 9:58:33 PM UTC-8, Stefano Ciccarelli wrote:
>
> Read this 
> http://stackoverflow.com/questions/11525717/when-does-the-app-engine-scheduler-use-a-new-thread-vs-a-new-instance
>
> Bye
>
> Il giorno venerdì 22 febbraio 2013, Jerome O'Flaherty ha scritto:
>
>> Guys,
>>I have marked my application as threadsafe but it does not seem to 
>> every call the application multiple times, rather the App Engine always 
>> create a new instance. I have tested this by basically sleeping for 20 
>> seconds on one request (the application implemented a Jersey REST service) 
>> and with nothing else being executed all new requests cause the App engine 
>> to launch a new instance, in fact multiple new instances?
>>
>>   Is there something else I need to do to allow a single instance handle 
>> multiple requests? Its seems to be a complete waste and more/less causes 
>> the app engine to be much more expensive than it needs to be.
>>
>> All help appreciated.
>>
>> Thanks 
>>
>> Jerome
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Google App Engine" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to google-appengine+unsubscr...@googlegroups.com.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> Visit this group at http://groups.google.com/group/google-appengine?hl=en
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
> -- 
> Sent from Gmail Mobile
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Many cold start problems recently.

[Kristopher Giesing]

Be careful how you analyze the situation with your instances.  When I was 
playing with resident instances, I assumed that they represented a "floor" 
you wouldn't drop below in times of low traffic, but that's not quite what 
they do.  Rather, they represent a pool of *deliberately idle* resources 
that can absorb spikes.

When working according to Google's intent, resident instances will absorb 
incoming traffic, but as soon as they become busy (with even one request) 
dynamic instances will spin up to offset the loss of idle instances.  Since 
this happens very close together, it's easy to assume that the dynamic 
instance was spun up to handle a given request and that the resident 
instance got nothing.  But in my particular case, what happened was that 
the resident instance got the first request, concurrently with the warmup 
for the dynamic request, and then all subsequent requests went to the 
dynamic instance.

Once I understood what resident instances do, I realized they do not - by 
design - solve the problem I wanted to solve, and I stopped using them 
altogether.  I never actually produced evidence to demonstrate that traffic 
was going to a cold instance when a resident instance was available. I 
believe others when they say they have such evidence, but I also strongly 
suspect that Google lumps all such claims into the same "not understanding 
what resident instances are supposed to do" bucket and ignores them.

- Kris

On Wednesday, March 6, 2013 5:45:30 PM UTC-8, Cesium wrote:
>
> Tapir, 
>
> This is an ongoing issue we have suffered with. 
>
> Get used to it. There will be no (useful) response from G. 
>
> David 
>
> On Tuesday, March 5, 2013 6:52:28 PM UTC-7, Tapir wrote: 
> > There is a resident instance obviously there. But the GAE scheduler 
> often ignores it totally and always creates a new instance then the let the 
> new instacne to handle the new request. 
> > What is the functionality of the resident instance? If the scheduler 
> always creates a new instance, the why put a resident instance there? 
> >   
> > It really make the user experience very bad. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Question about pushing messages to native apps

[Kristopher Giesing]

I ended up writing my own solution, which is essentially a replacement for 
the channel APIs.

The solution involves a node.js service that multiplexes to the clients.  I 
used websocket-node (https://github.com/Worlize/WebSocket-Node) on the 
node.js end, and SocketRocket (https://github.com/square/SocketRocket) on 
the iOS end. I had tried several other persistent-connection solutions for 
node, but none of them gave me the combination of flexibility and 
reliability that I needed.

I've been considering posting the code somewhere since it's pretty simple. 
 The advantage to it is that it's free (other than hosting costs, which run 
me $200/year, but I was already paying that).  The disadvantage is that, 
well, it's custom, so it's not as well tested as some other solutions might 
be.

- Kris

On Tuesday, March 19, 2013 2:06:10 PM UTC-7, Vinny P wrote:
>
> Hi Arthur,
>
> I'm not the original poster, but I deployed a simple communications app 
> recently and I used a new company called Firebase. Firebase is still in 
> beta, but it basically handles the entire communications backend for you, 
> and all you need is some javascript on your side. Here's a quick tutorial 
> on it: https://www.firebase.com/tutorial/#gettingstarted
>
> (Not affiliated with them, just a happy customer.)
>
> -Vinny P
>
>
>
>
> On Monday, March 18, 2013 2:33:57 PM UTC-5, Arthur Wiebe wrote:
>>
>> Hey Christoph, may I ask what you ended up doing?
>>
>> I thought about registering one gtalk account and use it within the game 
>>> client (register each client with a unique ressource, or maybe with a 
>>> ressource per game). So basically the GAE app would send messages to 
>>> my_customapp [at] gmail [dot] com/, but i'm not sure if this 
>>> would be allowed by google. Maybe someone here has some information about 
>>> that?
>>
>>
>> I'm considering doing that as well. Unless there is a better way.
>>
>> On Sunday, 15 January 2012 16:45:48 UTC-5, Christoph Grossegger wrote:
>>>
>>> thank you for mentioning and sharing your experiences with pubnub, 
>>> althought it seams a bit expensive for my purpose (at least the pay as you 
>>> go system, haven't calculated the prepaid options yet). It looks 
>>> interesting for applications with somehow "moderate" update rates / pushes, 
>>> since you get the whole package from client to server apis, but in my case 
>>> here, it looks really expensive. 
>>>
>>> If i understand the pricing model right, i would pay 5 credits per 
>>> message on a broadcast to 4 players (currently the maximum player size per 
>>> game), 1 to the system and 1 for each player. One credit costs "only" 
>>> $0.0001 (which makes $0.0005 per broadcast), which doesn't look much, but 
>>> throughout a game, there are a few of those. Let's say each player performs 
>>> every 4 seconds an action that requires a broadcast, results in 1 broadcast 
>>> per second per hosted game. That would cost a lot of money. Guess that an 
>>> ec2 instance would cost way less and running the game logic directly their 
>>> would also reduce the latency and the load of other instances. 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Bad news for GAE/Java from Google I/O

[Kristopher Giesing]

What is AOP in this context?

On Wednesday, May 15, 2013 4:52:51 PM UTC-7, Jeff Schnitzer wrote:
>
> I attended the "Autoscaling Java" session at Google I/O. In summary, the 
> advice is:
>
>  * Don't use dependency injection.
>  * Don't use AOP.
>  * Hardcode configuration values as much as possible.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Frustrated by logs

[Kristopher Giesing]

I'm having a devil of a time using the logs to debug my application.

There's a basic pattern of access that I'm trying to troubleshoot.  In 
order to do this, I would like to analyze correlations between the 
following properties of requests:

- Request path
- Request status
- Instance ID used to serve the request

If I could filter on the first two properties in the admin console, I would 
probably be able to diagnose the issue.  But that never seems to work 
properly; the admin console seems to give me some random subset of the 
relevant logs - sometimes none, sometimes a few, but never all of them.

So I tried downloading the logs using appcfg.sh, and then filtering the 
logs myself.  That works - except that the amount of data per request that 
you get from downloading logs doesn't include the instance ID used to serve 
the request!

I'm getting enormously frustrated by this.  Am I missing something about 
the admin console, or is its search function really this broken?  Is there 
some way to get more verbose logging from the logs-download feature of 
appcfg.sh?

Any insights or help would be greatly appreciated.

Thanks,

- Kris

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Re: Bad news for GAE/Java from Google I/O

[Kristopher Giesing]

I don't think so.  You just put the X requests into the queues for the N 
instances already running.  This gives you additional latency for the X 
requests, of course - it's not free - but if the latency added is less than 
the instance startup time, then it's a better solution than what we have. 
 In my own case, the queue length for existing instances is never greater 
than 1 or 2, and the average latency per request is about 200ms, while 
instance startup is 10s.  The math in my case is pretty simple: it's hardly 
ever really worth spinning up a 2nd instance, but GAE does it pretty 
frequently.

Someone should craft a Google Code Jam problem based on this issue.

- Kris

On Thursday, May 23, 2013 11:55:11 AM UTC-7, Tom wrote:
>
> I'm not that experienced with GAE, but I'm wondering whether it really is 
> that simple.  If an instance of my app takes 10s to start up, and my app 
> can, at peak, receive X requests in a 10s period, then wouldn't I require 
> close to X idle instances running all the time to satisfy your criteria. 
>  And wouldn't that be prohibitively expensive for most apps?
>
>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Re: Bad news for GAE/Java from Google I/O

[Kristopher Giesing]

Oh, also: Google uses GAE internally.  I've always assumed that the primary 
motivation for establishing Go support came from inside Google.  (Not 
necessarily a bad thing - Google is on the cutting edge of web tech in a 
lot of ways, so if Google internally sees value in it, there's probably a 
good reason.)

- Kris

On Thursday, May 23, 2013 11:55:11 AM UTC-7, Tom wrote:
>
> One final point - I'm baffled at Google's decision to support Go on GAE. 
>  When I looked at Go and wondered about design decisions that seemed odd, 
> the answer I always got was that it was designed to reduce build times for 
> enormous systems.  How does that primary design criteria make it suitable 
> for GAE?  If they had instead added a runtime for something like LLVM then 
> people like myself (and the vast number of other devs who know C/C++/OC) 
> could take advantage of the near-instantaneous startup times that you are 
> talking about, with our existing skills and libraries.
>
>
> Tom
>
> On Thursday, May 23, 2013 2:07:18 PM UTC-4, Ryan Chazen wrote:
>>
>> And it's possible to not use app engine at all, and then not have to 
>> worry about how fast your app starts. As a bonus, it's far cheaper as well! 
>> "Possible" is never a useful word to throw around here - it's possible to 
>> rewrite your java webapp in Go, it's possible to convince people they don't 
>> even need a webapp and just use pen and paper.
>>
>> The point is, GAE/J pointing user requests to servers that have not 
>> finished loading is broken, and Google needs to fix it if they want to 
>> compete with Heroku/Azure/etc who all seem to have this issue sorted out. 
>> This isn't some kind of technical impossibility here - every other hosting 
>> provider of this type manages to solve this issue. And GAE is the most 
>> expensive of the lot in terms of compute resources. GAE should be offering 
>> the best solution, not a "jump through hoops and pray it works until the 
>> next GAE release where everything crawls at half speed for a day" solution.
>>
>>
>>
>> On Wed, May 22, 2013 at 11:53 AM, Bediako George <
>> bediako...@lucidtechnics.com> wrote:
>>
>>> So our Airlift application framework starts up pretty much immediately 
>>> on App Engine for Java.
>>>
>>> It runs on the Java runtime, but developers write request handlers in 
>>> JavaScript via Rhino.  Even though it is production ready (we do have 
>>> several customers using it already) it is not ready for public consumption 
>>> (we are looking to release it at the end the summer).
>>>
>>> I am not mentioning this as an alternative to what you are doing. 
>>>  Instead, I want to make the point that it is possible to create a 
>>> framework in Java that plays well with App Engine.
>>>
>>> https://github.com/LucidTechnics/Airlift
>>>
>>> Bediako
>>>
>>> On Friday, May 17, 2013 2:20:53 AM UTC-4, Marcel Overdijk wrote:

 This is an interesting question indeed.

 I don't believe startup times for Java will become better on GAE; it's 
 also very typical for in Java land that startup times take > 30s for 
 medium 
 to large apps or depending on the frameworks chosen.
 This is no problem when you up front spin up the number of required 
 instances like on a VPS or CloudFoundry PaaS.
 One of the great things about GAE is the programming API and the 
 autoscaling part, but this autoscaling (and thus spinning up and killing 
 instances) bites back unfortunately.

 Couldn't Google prohibit cold requests being served to users? In many 
 cases it would better to have latency when a requested is routed to a warm 
 instance.
 I think this would solve many problems. What do you think?

 To bad Google is not participating in these discussions.

 But with great technologies and frameworks being delivered by Google 
 (like Angular JS) Google cannot be taken seriously when they say just go 
 back 10 years and use servlets, static factories, hard coded configs etc. 
 This is a real development nightmare.

 ^M


 On Friday, May 17, 2013 1:21:22 AM UTC+2, jeffrey_t_b wrote:
>
> Jeff, I believe that you had asked on this list, a while ago:  In what 
> circumstance is it _ever_ good for user requests to see cold starts?
>
> Did you ever get an answer to that?  That is the part that puzzles me 
> still.  Is it just too hard?  Maybe they don't have a _scalable_ 
> algorithm 
> for directing requests to already-existing instances?
>
> Anyway, with all of the focus on the Compute Engine side, I wonder if 
> improvements to App Engine are going to deprioritized.
>
>
>
> On Wednesday, May 15, 2013 4:52:51 PM UTC-7, Jeff Schnitzer wrote:
>>
>> I attended the "Autoscaling Java" session at Google I/O. In summary, 
>> the advice is:
>>
>>  * Don't use dependency injection.
>>  * Don't use AOP.
>>  * Hardcode configuration values as mu

Re: [google-appengine] Re: Frustrated by logs

[Kristopher Giesing]

Comments below...

On Saturday, May 25, 2013 1:01:12 AM UTC-7, Nick wrote:
>
> The logs, while good to have, are a super PITA to use.
>
> Things that would be great to fix:
>
>- The search option labelled 'Since' is exactly the opposite of what 
>it says. Everyone i've ever spoken to gets confused by this, the logs work 
>backwards from this time, not forwards. I must have helped at least 10 
>people understand this to use the logs.
>
> This was the crux of my issue.  I suspected that "since" didn't do what I 
wanted, but I had no idea what it actually did.

Now that I know how the system works, I have to say, the UI is awfully 
misleading.  I know Google isn't exactly famous for its HCI, but... jeez. 
I've never seen a search return an empty results list and then give you a 
"next page" link.  "Next page" of what result set?  Isn't it empty?  It 
doesn't make any sense.

Imagine using Google to search the web and have it give you an empty result 
set, with a link at the bottom that says in tiny print "Last IP address 
searched: 53.207.121.84. Use the Next link to search higher IP ranges." 
 Would you use that search engine?

I understand that the search can take a long time if you search 
*everything*.  This is why I thought "Since" would you a maximum time into 
the past where the search would halt.  And additionally the search would 
stop after the maximum rows specified in the "Rows" pop-up.  If that was 
the way the search feature actually worked, it would be pretty useful; 
you'd just have to change the default for "Since" to (now minus 1 hour) 
rather than (now) and viola, very usable UI.

>
>- On the dashboard you can see errors in the last 24 hours, and if you 
>click through they take you into the logs to see what the problem is. I 
>have never, ever seen this work. The filter it applies (status and path) 
>flat out doesn't work and apparently never has.
>
> It *does* actually work... as long as you click "next" an indeterminate 
number of times.  The filter is correct, but the time range searched is an 
arbitrary distance from the request log you want.  I didn't realize this 
until this thread educated me on how the time ranges really function.

- Kris

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Re: Frustrated by logs

[Kristopher Giesing]

Thanks Takashi.  I think I used the Python appcfg.py script for something 
else a long time ago - so IIRC it's possible to use this script with Java 
apps.  Is that true?

- Kris

On Friday, May 24, 2013 2:32:16 PM UTC-7, Takashi Matsuo (Google) wrote:
>
>
> Thanks Matthew,
>
> I confirmed that you can download logs with instance_id by running the 
> Python appcfg.py with the '--include_all' option as follows:
> $ appcfg.py request_logs --oauth2 -A APP_ID --version VERSION 
> --include_all LOG_FILENAME
>
> Unfortunately, it doesn't seem Java appcfg have that option yet though.
>
>
> On Fri, May 24, 2013 at 2:00 PM, Matthew Blain 
> 
> > wrote:
>
>> The instance is available today in the logs you can download. I recently 
>> updated logparser.py to not fail when it shows up in the logs.
>>
>> https://code.google.com/p/google-app-engine-samples/source/browse/trunk/logparser/logparser.py
>>
>> (Looks like I didn't update the docstring for this, but the fundamentals 
>> are correct.)
>>
>>
>> On Friday, May 24, 2013 12:24:24 PM UTC-7, Takashi Matsuo (Google) wrote:
>>
>>>
>>> As Vinny said, certainly BigQuery is something you can consider.
>>> Here is another project for ingesting App Engine logs into BigQuery:
>>> https://code.google.com/p/**log2bq <https://code.google.com/p/log2bq>
>>>
>>> -- Takashi
>>>
>>>
>>> On Fri, May 24, 2013 at 11:49 AM, Vinny P  wrote:
>>>
>>>> Hello Kristopher,
>>>>
>>>>
>>>> On Friday, May 24, 2013 10:51:23 AM UTC-5, Kristopher Giesing wrote:
>>>>>
>>>>> I'm getting enormously frustrated by this.  Am I missing something 
>>>>> about the admin console, or is its search function really this broken?  
>>>>> Is 
>>>>> there some way to get more verbose logging from the logs-download feature 
>>>>> of appcfg.sh?
>>>>>
>>>>
>>>> Yup, you're correct. Searching logs can be a PITA.
>>>>
>>>> Personally, I use a combination of a homebuilt logging inspector (a 
>>>> backend using the Logging API to inspect error logs) and Google BigQuery 
>>>> to 
>>>> analyze my logs. Streak wrote up a blog entry about using Google BQ to 
>>>> inspect logging, you can read it here: http://blog.streak.com/**
>>>> 2012/07/export-your-google-**app-engine-logs-to.html<http://blog.streak.com/2012/07/export-your-google-app-engine-logs-to.html>
>>>>  .
>>>>
>>>>
>>>>
>>>> -
>>>> -Vinny P
>>>> Technology & Media Advisor
>>>> Chicago, IL
>>>>
>>>> My Go side project: http://invalidmail.com/
>>>>
>>>>  -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Google App Engine" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to google-appengi...@**googlegroups.com.
>>>> To post to this group, send email to google-a...@googlegroups.**com.
>>>>
>>>> Visit this group at http://groups.google.com/**
>>>> group/google-appengine?hl=en<http://groups.google.com/group/google-appengine?hl=en>
>>>> .
>>>> For more options, visit 
>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>  
>>>>  
>>>>
>>>
>>>
>>>
>>> -- 
>>> Takashi Matsuo | Developers Programs Engineer | tma...@google.com
>>>  
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Google App Engine" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to google-appengi...@googlegroups.com .
>> To post to this group, send email to 
>> google-a...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/google-appengine?hl=en
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> Takashi Matsuo | Developers Programs Engineer | tma...@google.com
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Re: Frustrated by logs

[Kristopher Giesing]

And as an addendum, once I finally understood how to get to the logs I 
needed, I was able to diagnose the issue (at least from the server side - I 
now know the fault is somewhere on the client).  Without being able to 
trace all the events, including server instance IDs, I wouldn't have been 
able to make that determination.

On Saturday, May 25, 2013 12:37:57 PM UTC-7, Jeff Schnitzer wrote:
>
> I do want to point out that the log system is actually one of GAE's best 
> features. If you spend any time working on Heroku or Appfog or EB you will 
> be utterly shocked at how primitive the logging systems there are.
>
> This is not to say that GAE logging is perfect, but it's *miles* ahead of 
> other PaaS systems. My biggest complaint with GAE's log system is that it 
> doesn't remember the state of the UI - how many times have I changed the 
> dropdown from 20 to 50 entries? I'm half-tempted to write a chrome 
> extension to "fix" this problem.
>
> Jeff
>
>
> On Sat, May 25, 2013 at 1:01 AM, Nick >wrote:
>
>> The logs, while good to have, are a super PITA to use.
>>
>> Things that would be great to fix:
>>
>>- The search option labelled 'Since' is exactly the opposite of what 
>>it says. Everyone i've ever spoken to gets confused by this, the logs 
>> work 
>>backwards from this time, not forwards. I must have helped at least 10 
>>people understand this to use the logs.
>>- On the dashboard you can see errors in the last 24 hours, and if 
>>you click through they take you into the logs to see what the problem is. 
>> I 
>>have never, ever seen this work. The filter it applies (status and path) 
>>flat out doesn't work and apparently never has. 
>>- It would be super, super useful if you could filter out different 
>>log levels. For example, if you filter for anything with info and above, 
>>you still see all debug logs. This means even when looking for errors or 
>>warnings, you have to look by eye through plenty of lines of logs. An 
>> extra 
>>option to show only log levels above a certain level would be really 
>> useful 
>>- The ability to control how long to search backwards through logs 
>>would be great. Sometimes, you really need to know if something happened 
>> at 
>>all in the last month, and i'd rather pay to search a months or a years 
>>worth of logs than sit there clicking 'Use Next link to search older 
>>records.'. Maybe having the timestamp filter as a 'from' and 'to', 
>>rather than 'Since' would help. 
>>
>> I appreciate that distributed logging and live log search is a 
>> non-trivial problem, but it feels like someone already has done all the 
>> hard work and that the log viewer just sort of stopped progressing at some 
>> point.
>> Having said that, the addition of being able to search again for older 
>> entries back through time was really useful. Before that you had to be 
>> lucky enough to catch problems pretty quickly.
>>
>>
>> On Saturday, May 25, 2013 7:32:16 AM UTC+10, Takashi Matsuo (Google) 
>> wrote:
>>
>>>
>>> Thanks Matthew,
>>>
>>> I confirmed that you can download logs with instance_id by running the 
>>> Python appcfg.py with the '--include_all' option as follows:
>>> $ appcfg.py request_logs --oauth2 -A APP_ID --version VERSION 
>>> --include_all LOG_FILENAME
>>>
>>> Unfortunately, it doesn't seem Java appcfg have that option yet though.
>>>
>>>
>>> On Fri, May 24, 2013 at 2:00 PM, Matthew Blain wrote:
>>>
>>>> The instance is available today in the logs you can download. I 
>>>> recently updated logparser.py to not fail when it shows up in the logs.
>>>> https://code.google.com/p/**google-app-engine-samples/**
>>>> source/browse/trunk/logparser/**logparser.py<https://code.google.com/p/google-app-engine-samples/source/browse/trunk/logparser/logparser.py>
>>>>
>>>> (Looks like I didn't update the docstring for this, but the 
>>>> fundamentals are correct.)
>>>>
>>>>
>>>> On Friday, May 24, 2013 12:24:24 PM UTC-7, Takashi Matsuo (Google) 
>>>> wrote:
>>>>
>>>>>
>>>>> As Vinny said, certainly BigQuery is something you can consider.
>>>>> Here is another project for ingesting App Engine logs into BigQuery:
>>>>> https://code.google.com/p/**log2**bq<http

Re: [google-appengine] Puzzled by promotion of Go for high performance web serving

[Kristopher Giesing]

Personally, I found his observations valuable.

On Sunday, June 16, 2013 12:41:02 AM UTC-7, alex wrote:
>
> I don't know where you get your "experience" from but you could've just 
> said something like "Go is not for me" or "I don't like Go". Otherwise, 
> your post is what looks silly.
>
> -- alex
>
> On Saturday, June 15, 2013 8:15:54 PM UTC+2, Jeff Schnitzer wrote:
>>
>> I finally have some significant hands-on experience with Go (not on GAE). 
>> It's definitely an improvement over C or C++, and seems "about right" for 
>> building things you would otherwise write in C or C++.
>>
>> On the other hand, it seems like a poor platform for building large 
>> complicated web applications:
>>
>>  * The module system is fairly primitive and doesn't take versioning into 
>> account.
>>
>>  * No exceptions. This (and the "debate" around it) is just silly.
>>
>>  * Bringing back the distinction between stack objects and heap 
>> references. It seems like this could be a potential boon to performance, 
>> but according to http://benchmarksgame.alioth.debian.org/ it doesn't 
>> appear to yet be the case. Probably this is due to Go's poor GC (and Java's 
>> highly-refined GC), which may change in the future. But you pay for this 
>> distinction in terms of code complexity up front.
>>
>>  * The IDEs are still pretty primitive. Go seems to have inherited VT100 
>> text-editor culture, which is sad. See this comment from Rob Pike: "Syntax 
>> highlighting is juvenile." (
>> https://groups.google.com/d/msg/golang-nuts/hJHCAaiL0so/kG3BHV6QFfIJ). 
>> This is retarded, and makes me wonder what other stupidity is getting 
>> encoded into the language/culture/tools (besides the lack of exceptions).
>>
>> It's pretty obvious that Go comes from old-school C hacker culture - 
>> people that have probably never worked on webapps. So don't expect Go to be 
>> suitable for writing webapps.
>>
>> Jeff
>>
>> On Fri, Jun 14, 2013 at 9:47 AM, Tom  wrote:
>>
>>> I saw the new blog post here promoting Go for "high performance" apps on 
>>> App Engine
>>> http://blog.golang.org/go-and-google-cloud-platform
>>>
>>> I remember reading about Go with considerable interest when it was 
>>> announced.  The controversial and particularly unique elements of Go's 
>>> design were justified with the explanation that Go was designed for 
>>> building massive systems.  In particular a number of design concessions 
>>> were made such that massive code base could be built quickly.  
>>>
>>> I don't mean to put Go down - I wasn't building massive systems so I 
>>> didn't pursue the language and know nothing of it beyond its high level 
>>> design justification.  For all I know it is a great language.
>>>
>>> My point in making this post is that I hope Google will, with time, also 
>>> support C-based languages for web serving on GAE, rather than requiring the 
>>> vast number of us who already know them so well to learn a new language 
>>> that was designed for such a different purpose.
>>>
>>> I will add that I'm currently using GAE/J to back an Android app, and 
>>> the ability to share code between client and server is terrific, so I think 
>>> there is a lot of value in adding new GAE runtimes that correspond to 
>>> client technologies.
>>>
>>>  -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Google App Engine" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to google-appengi...@googlegroups.com.
>>> To post to this group, send email to google-a...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/google-appengine.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Puzzled by promotion of Go for high performance web serving

[Kristopher Giesing]

Do we know Andrew works on GAE specifically, rather than the Go language 
and support for it generally?

- Kris

On Tuesday, June 18, 2013 10:44:54 AM UTC-7, vlad wrote:
>
> @Andrew: I do not have any vitriol toward Go or GAE. Think of these posts 
> as tough love :). I am GAE's loyal customer since 2009 and so is Jeff who 
> started this thread. Without sounding pompous we, and small startups and 
> indie developers like us, ARE your best customers. You are clearly entitled 
> to your opinion. Now think of what you are doing: Following in a good old 
> Google's tradition you are ignoring what customers are telling you. I know 
> Google keeps having  these wet dreams of Fortune 500 getting onto GAE en 
> masse. Let's be honest  - that has not happened. Why? - not because Go 
> runtime was not there. Rather because GAE team likes to overextend 
> themselves working on cute and interesting side projects.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Re: App Engine VM-based Backends - Trusted Tester Sign-up

[Kristopher Giesing]

>
> PS : Now that we've got these great new backends and all the goodness of 
>> BigQuery, CloudSQL, Datastore, ..., the only remaining "evil problem" in 
>> the AppEngine world is the behavior of the dispatcher which sends 
>> "user-facing requests to starting instances".
>>
>
> we have engineers dedicated to fixing this.  once we have an ETA that 
> we're more confident, we'll update the larger group.
>

That is absolutely fantastic news! 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Concurrency broken?

[Kristopher Giesing]

I saw strange instance behavior yesterday just after pushing a new 
deployment. I assumed it was something I'd done on my end and was about to 
post something.  Specifically, I'm seeing a lot of optimistic concurrency 
failures from Objectify and those requests are taking a long time to 
fulfill, and that seems to be impacting the # of instances required to 
service my low average QPS.
>
>
Things seemed to settle down for a while, but just the last few hours I'm 
seeing odd behavior again.

Maybe I'll throw some more rainbow skittles at the unicorns...

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: major MEMCACHE changes started October 5th

[Kristopher Giesing]

Are you sure this is something Google is doing, and not something another 
memcache client in your same data center is doing?

A more charitable explanation for all this is that memcache performance is 
hard to guarantee without explicit allocations (i.e. the paid option), and 
that you've been lucky up until recently.

- Kris

On Tuesday, October 8, 2013 10:24:12 AM UTC-7, James Gilliam wrote:
>
> Memcache continues to perform poorly; I suspect they are making many 
> changes to it.
>
> Saturday was awful -- aggressively purging memcache, Sunday was better, 
> Monday was worse than Sunday.
>
> At this point, not sure what to do ... are we dealing with just code 
> instability or some fundamental change?
>
> Really wish GAE would test these changes before deploying them.
>
> Or at least alert the community to whatever changes they are making.
>
> On Sunday, October 6, 2013 11:57:02 AM UTC-7, James Gilliam wrote:
>>
>> GAE has drastically changed the way MEMCACHE works; as a result my 
>> application (ogeekcom) overall usage jumped by approximately 5 times with 
>> the same approximate bandwidth output.  Like a 400% increase in price.
>>
>> Specifically, they are purging shared memcache very aggressively -- 
>> possible in an effort to force people to signup for paid memcache.
>>
>> As a result of this change, my application is using many more datastore 
>> reads and many more instances to compensate for the poor memcache 
>> performance.
>>
>> Like always, this was done without any announcement at all.
>>
>> If they made this change to increase make applications cost more to run, 
>> it is illegal.  
>>
>> There is no problem with them offering a premium service for memcache, 
>> but it is illegal to degrade the previous service to force people into the 
>> paid model.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] URGENT Please help.

[Kristopher Giesing]

I'd strongly recommend Objectify as a persistence layer.  It's designed for 
App Engine and works very well in my experience.  Memcache caching is very 
easy to enable, nearly transparently.

http://code.google.com/p/objectify-appengine/

- Kris

On Wednesday, December 11, 2013 5:51:19 AM UTC-8, Jayakrishnan wrote:
>
> Yeah thank you so much Nick.  I am going to deploy to a new app and hence 
> can temporarily be safe :)
>
> I think the problem can be avoided by using memcache instead of querying 
> datastore, because app will be subjected to some heavy loads.
>
>
> On Wed, Dec 11, 2013 at 6:13 PM, Nickolas Daskalou 
> 
> > wrote:
>
>> You've used up your daily free quota for datastore reads.
>>
>> The free quotas reset every 24 hours, and it looks you are still 20 hours 
>> away from a reset.
>>
>> If you need to get your app working before then, you will need to enable 
>> billing on this app, or alternatively, be cheeky and deploy to a new app 
>> just before your client presentation.
>>
>> Also note that you used up the 50,000 free datastore reads quota within 4 
>> hours, and if this surprises you, it's possible your app is misbehaving 
>> (e.g. Are you using offsets in your queries? They are bad, use cursors 
>> instead, or change your data model (the Datastore is not suitable for all 
>> use cases)).
>>
>> I hope that helps.
>>
>> Nick
>>  On 11/12/2013 11:27 PM, "Jayakrishnan" > 
>> wrote:
>>
>>>  Forgot to attach file 
>>> PFA
>>>
>>>
>>> On Wed, Dec 11, 2013 at 5:56 PM, Jayakrishnan 
>>> 
>>> > wrote:
>>>
 Hi,

 I get the below error while I try to enter my website,
 The API call datastore_v3.RunQuery() required more quota than is 
 available.

 Also please find the attached screenshot of my appengine console.

 What do these logs tell me? When can my site go up again? 
 The situation is worse since I have a client presentation tomorrow 
 showing the working of website .

 Thanks in advance
 -- 
 *Jayakrishnan Damodaran*
 *Uroleaf Technologies*
 Skype: jayakrishnand88
 Phone: 8281853554
  
>>>
>>>
>>>
>>> -- 
>>> *Jayakrishnan Damodaran*
>>> *Uroleaf Technologies*
>>> Skype: jayakrishnand88
>>> Phone: 8281853554
>>>  
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Google App Engine" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to google-appengi...@googlegroups.com .
>>> To post to this group, send email to 
>>> google-a...@googlegroups.com
>>> .
>>> Visit this group at http://groups.google.com/group/google-appengine.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Google App Engine" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to google-appengi...@googlegroups.com .
>> To post to this group, send email to 
>> google-a...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/google-appengine.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> -- 
> *Jayakrishnan Damodaran*
> *Uroleaf Technologies*
> Skype: jayakrishnand88
> Phone: 8281853554
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: How to upload an image from an Android Client to the datastore and get it back (or send it to another client)?

[Kristopher Giesing]

Yes, it's possible to do this with Google App Engine.  There are a lot of 
options; you'll need to make some design decisions to start, and then the 
documentation can help you with the implementation.

First, you need to decide whether the game state should be stored on the 
server or transient.  That determines whether you need to use the data 
store.  Most likely you'll want the game state to be stored, but I don't 
know your specific requirements so I could be mistaken.  Assuming you want 
to use the data store I *highly* recommend you use Objectify rather than 
the built-in JPA or JDO support in App Engine.  Objectify has a lower start 
up cost so is better for overall performance, and its APIs are tailored to 
GAE so you avoid some of the weirdness in JDO/JPA.

In addition to the game state it sounds like you want to store images. 
 Storing image data in the data store might not work for you depending on 
the image size; if that's the case you may want to look into the Blobstore 
APIs.  I have not personally used them so I don't have much to say there.

Next, you need to decide how players submit moves, and how they will be 
informed of moves by other players.  Google's documentation suggests using 
the Channel APIs, which are essentially a wrapper around WebSocket.  There 
are some significant limitations to Channel, though, not least of which is 
that the client has to be JavaScript (for Android, this means using an 
embedded WebView).  Channel is also designed to be one-way (server to 
client); for client to server messages Google suggests using HTTP POST 
requests.

An alternative to Channel is to use HTTP requests in both directions: POST 
for submitting moves, and GET (in a polling sense) to retrieve moves.  GET 
polling can be less friendly to network bandwidth and battery though.

In my own (iOS) game I decided to use raw WebSockets instead and create my 
own wrapper, foregoing the Channel APIs.  There are WebSocket libraries for 
both iOS and Android (though I don't have any experience with the Android 
ones) - this means your client doesn't have to be a WebView.  In addition, 
WebSocket can be used for bidirectional messaging, meaning you can use one 
transport for both move submission and notification.  However, if you're 
using the Blobstore to store data, you may want to use HTTP requests to 
post moves anyway, since (as I understand it) the Blobstore already has an 
HTTP request interface.  Again though, I haven't used Blobstore myself, so 
YMMV.

Finally, a comment on Google cloud endpoints.  The cloud endpoints system 
is not something I've used, but from what I can tell, it is a code 
generation system designed to make it easier to develop both the client and 
server together using a single API definition (somewhat like IDL).  If 
that's the case, then there's nothing you can do with cloud endpoints that 
you couldn't do by hand.  I would recommend designing the system by looking 
at the underlying capabilities of App Engine and seeing which ones meet 
your needs, and then consider cloud endpoints as a kind of "syntactic 
sugar" that can help with the implementation.

Good luck,

- Kris

On Sunday, January 5, 2014 2:49:42 PM UTC-8, Aaron Villalpando wrote:
>
>
> I've been doing GAE tutorials the entire week and haven't been able to 
> send an image to the datastore using google cloud endpoints and retrieve it 
> (maybe with modifications done serverside).
>
>
> Basically I would like to create an asynchronous multiplayer game using 
> GAE and Android where Person A creates an image, then sends it to the 
> server, server sends it to Person B, who edits the image, and then Person B 
> sends it back to A (and so on).
>
>
> Do you guys have any recommendations on how to go about implementing this?
>
> I tried looking at the tictactoe 
> sample
>  to 
> learn more about the relationship between the backend and the android 
> client but I haven't been able to figure out how to do something like I 
> described. Not only that, but the tutorial
> seems to be all over the place for beginners like me. If they explained 
> that tictactoe sample like they did with the Mobile Assistant 
> Tutorial
>  it 
> would be amazing.
>
>
> If any of you have any helpful, very simple functional samples using GAE 
> for android in java relating to this type of problem (image sharing through 
> GAE using Android) it would be extremely helpful.
>
> Thank you.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
Fo

Re: [google-appengine] appengine provided libs for java

[Kristopher Giesing]

You could probably still do without the labs jar - I think that is all 
optional APIs.  (Assuming, of course, that you don't actually use any of 
the labs APIs.  And, caveat - I haven't actually tried it.)

- Kris

On Tuesday, February 18, 2014 11:48:06 AM UTC-8, Rafael Sanches wrote:
>
> I tried removing those files in my maven script and it decreased the final 
> instance size by 20mb. 
>
> The problem is that it doesn't work, because everytime I try to do 
> something on the production instances it explodes: 
>
> java.lang.NoClassDefFoundError: com/google/appengine/api/utils/SystemProperty
>
> Sadily, it seems that the appengine deploy script has to upload all the 
> jar classes, instead of uploading just the interface stubs. 
>
> I wish they would fix this, but Java seems to be something that they 
> regret ever supporting..
>
> thanks
> rafa
>
>
> On Tue, Feb 18, 2014 at 10:23 AM, husayt  >wrote:
>
>> I am trying to cut down the size of deployed java app. 
>>
>> The two largest files are:
>>
>>- appengine-api-labs-1.8.9.jar
>>- appengine-api-1.0-sdk-1.8.9.jar
>>
>> I am wondering, if I do have to deploy these libs. These files are part 
>> of GAE framework and I guess they would be expected to already exist on GAE 
>> servers.So why not to mark them as provided?
>>
>> What is the recommended way to go about them?
>>
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Google App Engine" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to google-appengi...@googlegroups.com .
>> To post to this group, send email to 
>> google-a...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/google-appengine.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Min Pending Latency -- does it really do anything?

[Kristopher Giesing]

I have yet to talk to a GAE user who *didn't* misunderstand this part of 
the docs on first read.  It's one of the most common issues people have 
when they first come to this group.

- Kris

https://developers.google.com/appengine/docs/adminconsole/
>>> performancesettings#minimum
>>>
>>
>> This document doesn't mention 'automatic'.
>>
>
> Its telling you what enabling 'idle instances' does. Going back to 
> 'automatic' in effect turns the feature off. 
>
> (glossing over a few details) 
>  
>
>>
>> I feel I really can't understand many GAE documents very well.
>>
>
> One of the main issue, is they leave a lot unsaid, you have to infer. Read 
> between the lines. 
>
> Plus the inevitable case that things change, and the docs are not always 
> in sync. 
>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Min Pending Latency -- does it really do anything?

[Kristopher Giesing]

Because by definition, resident instances don't serve any traffic.  That 
means you are eating up 24 instance hours of idle time each day, leaving 
you only four hours each day to serve traffic.

I had this exact problem while my app was in development, and I couldn't 
figure out why Java developers weren't screaming bloody murder about it. 
 Then I did three things:

1) I gave up on trying to configure residency and latency, and just left 
everything at the default values
2) I rewrote the app away from JDO and started using Objectify
2) I optimized my app to use fewer API calls and less CPU

When I did those two things, the problems I was seeing with the scheduler 
magically disappeared.  I believe that the scheduler was behaving the way 
it did because it was reacting to the CPU, memory usage, and API call 
pattern of my app - that is, it assumed that due the combination of those 
metrics, my app's single instance was incapable of handling any more 
traffic and kept trying to spin up more instances.  Before I was using 
Objectify this spin-up cost was prohibitive; after Objectify it was still 
noticeable, but manageable.  Then after I was done with my optimizations 
the spin-up attempts stopped.  I'm now below the free quota for instance 
hours every day, and only end up paying anything for read ops (which I'm 
fine with because I know where all those ops are going, and they're all 
necessary for my traffic levels).

- Kris


Well if you want to use a resident instance, then by definition you pretty 
>> much can't fit in the free limit!
>>
>
> Why? 24 hours is rally ok for my app.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Mobile Chess Game

[Kristopher Giesing]

I've implemented a multiplayer board game using an iOS client and a GAE 
service.  I'd be more than happy to talk about my experiences.  If you 
search for my posts on this forum you'll probably find earlier mentions of 
the overall architecture, or if you want more specific information I can 
follow up in this thread.

- Kris

On Sunday, March 16, 2014 8:34:13 AM UTC-7, Vinny P wrote:
>
>
> On Sat, Mar 15, 2014 at 7:21 AM, José Santos 
> > wrote:
>
>> I'm new in this stuff and I have a question for my future project !
>> Is It possible to use the Google Backend to implement the 
>> conditions/logics of a Chess game (in Java)
>> and then on an Android/IOS play the game with the info stored in the 
>> Backend ?
>>
>
>
> Yes you can. The backend doesn't care about the OS that the request 
> originates on. As long as your client application can speak regular HTTP to 
> the backend, that's all that matters.
>   
>  
> -
> -Vinny P
> Technology & Media Advisor
> Chicago, IL
>
> App Engine Code Samples: http://www.learntogoogleit.com
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Returning custom HTTP status codes from endpoints

[Kristopher Giesing]

You don't mention which language you're using. If this is Java, you'd call 
response.sendError(int errorCode, String message) on the servlet's 
HttpServletResponse input argument, but I don't know offhand what it would 
be in Go, Python, or PHP.

- Kris

On Tuesday, May 27, 2014 1:06:44 PM UTC-7, Matthew Flint wrote:
>
> Hello team,
>
> We all love REST-full-ness, so I'd like to return more REST-ful status 
> codes from my endpoints. (Example: 201 CREATED from a POST endpoint which 
> creates a resource).
>
> But I can't find any way to set the HTTP status code. Can anyone help 
> please?
>
> Some other (sad-path) status codes seem to be driven by throwing an 
> exception - eg. NotFoundException causes a 404. But I want to return a 
> different status code *and* XML/JSON in the response.
>
> Thanks all!
>   Matthew
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/d/optout.