Hmmm ... I think what I was trying to say is that if you bring pre-conceived notions of how to build a Java application on GAE you will get burnt. Once you understand how GAE for Java works you will choose not to use frameworks that were not designed to run in a Java GAE environment, OR as you said you will not use App Engine at all.
I was also posting this for the benefit of people that would read this thread and just think "Java is slow on GAE" and "Java has start up issues on GAE". That is simply not the case. Hence the use of the word "possible". Perhaps Sun is ultimately to blame for all of this ... "write once, run anywhere" is one of the best marketing slogans, but it also technically incorrect for more than one reason. This whole discussion seems to point to one of them. Bediako 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 <javascript:>> 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 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 a topic in the >> Google Groups "Google App Engine" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/google-appengine/Nz4Yt8V6PB0/unsubscribe?hl=en >> . >> To unsubscribe from this group and all its topics, send an email to >> google-appengi...@googlegroups.com <javascript:>. >> To post to this group, send email to >> google-a...@googlegroups.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/google-appengine?hl=en >> . >> 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
