Hey Guys, Just a quick 2.5cent idea.
The current situation for applications running on the app engine is that a request that causes instance spin up (be it first request, or the unlucky one in high load) is usually cancelled because of timeout (30s). I'm observing this situation even for "virgin" applications that do nothing more then return "Hello World". Now, what if application developers could define a special API call (much like mail delivery to the application is handled by GAE) that will be called when GAE decides to spin yet another instance. This could solve the problem of requests being "canceled" in high load while the new JVM instance is loading. The GAE could allocate a "finite" amount of time from the "warm up" call to the "start of request delivery" to the new jvm (something like 60 seconds?). The application developers could take advantage of this call (that will go to the "InitServlet") to do start up logic (population of MemCache, loading static maps from DataStore and co..) This could be poor's men solution for applications that *should* not lose requests, even if it's 1/100000. I know about the planned "reserved instances" feature, don't really see the logic in this though as this approach doesn't seem to scale well: Say I'm holding 5 reserved instances. What happens if my requests get a peak... a truly massive slashdot peak which in theory should require yet another (well just for ex.) 100 instances? If GAE launches them and instantly starts forwarding requests to them then, assuming each instance takes 15sec to load - ~(15sec*95instances*<amount of traffic coming in 1 sec>)*0.40 requests are timed out. That's bad. Comments? Maxim. -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
