Jeff is right. In my opinion there's no point starting a project and loosing time on something that's not going to grow. Unfortunately coding in Java like the cobol isn't scalable. Not only for code maintenance, but also for team morale.
I hope they fix this soon. On Fri, May 31, 2013 at 7:54 AM, Jeff Schnitzer <j...@infohazard.org> wrote: > If your application is "just fine" using the low-level API then yes, your > applications are indeed simple. Mine are not. > > Latest metric: > > * 409 rest endoints > * 69 persistent domain classes > * ~25k lines of Java (half that again in coffeescript) > > ...and growing every week as customers demand more features. This is still > small beans as enterprise apps go. Abstractions like ORM let us scale > complexity. There's a reason why we don't write large applications in > assembler or C anymore. > > Jeff > > > On Fri, May 31, 2013 at 6:07 AM, Bediako George < > bediako.geo...@lucidtechnics.com> wrote: > >> >> >> On Thursday, May 30, 2013 10:46:23 AM UTC-4, Jeff Schnitzer wrote: >>> >>> By that definition there are no frameworks which work on GAE. >>> >>> >> I would not say there are none. But if your point is that there are >> plenty that work just fine on the traditional JVM platform but they suck on >> GAE, well I agree. >> >> >>> Persistence? You you're stuck with the low-level API. Everything else >>> (including Objectify) requires some amount of classloading and >>> introspection at startup. You just blew the 5s limit. >>> >> >> Are you suggesting that the low-level API is not very good? Works for me >> just fine ... could be that my applications are simple. Personally, I do >> not use Objectify or JDO. One of the reasons, and there are more than one, >> is precisely the point you mentioned. >> >> >>> >>> With all due respect to the Thundr developers - I'm sure it's a lovely >>> framework, but it requires defining all your endpoints in a JSON file. I >>> have hundreds of endpoints; if I wanted the "big chunk of XML" approach I'd >>> use http://mav.sf.net/ which I wrote back in 2001. Also, the API >>> requires returning things like JspView, which complicates testing. JAX-RS >>> (which requires classloading and introspection) allows us to make clean, >>> testable business methods... it's one of the few standards that came out of >>> the JCP that didn't suck in the first iteration. >>> >>> >> GAE can't expect us to roll back java development to 2001. Applications >>> have gotten a lot more complicated since then. And even if we did, how much >>> are we *really* going to improve startup time? Remember, cutting 30s down >>> to 10s is irrelevant - the user still abandoned our site at 5s. >>> >>> >> So I would say again, if you let go of some of the things that got Java >> to where it is today, and embrace Google App Engine for what it is, 1) I >> don't think you will experience 5 second start up times, and 2) given the >> scalable cloud architecture, you should not feel like you are rolled back >> to 2001. But if you are hell bent on using the Java frameworks that are >> optimized for other platforms and environments on App Engine, then that >> seems to me that you are ice skating up hill. You would be better off not >> using Google App Engine at all. >> >> >>> Jeff >>> >>> >>> >>> On Thu, May 30, 2013 at 2:51 AM, Bediako George < >>> bediako...@lucidtechnics.**com> wrote: >>> >>>> 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> 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/**LucidTechni**cs/Airlift<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/** >>>>>> to**pic/google-appengine/**Nz4Yt8V6P**B0/unsubscribe?hl=en<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. >>>>>> 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/**grou**ps/opt_out<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. > > > -- 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.
