Very unfortunate, but it's been clear that GAE/J has been getting the short end of the stick for awhile. Given the heavy costs for doing anything 'heavy' on GAE/J, and the prevalence of new hosting providers that can give you a full 8 core VM for similar prices to GAE's incredibly underpowered (and limited) instances, it seems like the right thing to do at this point is to bite the bullet and manage a few servers yourself. Often a pair of 8 core servers can do the same work load as an enormous number of GAE instances without any worry of strange app engine related bugs and limitations.
If GAE/J actually provided a better 'just works' solution that they should be then this would still be in favor of GAE, but with the countless hours you need to spend trying to optimize an app to boot quickly, you could easily spend half that time setting up an automated load balancer across some cheap hosting providers. This news that they're not even fixing these issues is the last straw here, and I'm going to begin transitioning off GAE/J. On Thursday, May 16, 2013 1:52:51 AM UTC+2, 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. > > In other words, go back to Java circa 2002. There was no discussion of > changing routing so that user requests don't see cold starts. I asked about > this in person - apparently they're still "talking about it" and nothing > has been done about it. > > I am sad. > > Jeff > -- 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.
