I tried reproducing your test to see what you were getting. I found the behavior when I ran the code in Hosted Mode and executed "serverMethod()" /twice/ before executing "anotherMethod()" (it didn't matter how many Hosted Browsers I had open).
When running the same test in real browsers (I used Firefox and Konqueror) the behavior was substantially different. Like I said, browsers generally only allow for 2 open connections per server. If you invoke a "connection hogging" method twice, you have no more connections to invoke a different method. That said, this is a strictly client side issue, GWT's RemoteServiceServlet is not limiting you to a single Thread. Try the same test with a normal HttpServlet and a RequestBuilder, you'll see the same results as you do with RPC. [email protected] wrote: > @shawn > Thats ok :) > > @jason > Well these "Tests" are very basic. i create an app with a simple rpc > call to the server that does something like this: > > public boolean serverMethod() { > for (;;) { > if (false) { > break; > } > } > return true; > } > > public boolean anotherMethod() { > return true; > } > > As you would expect, callingserverMethod() creates an infinite loop > tying up that thread. > > then i opened up a second, seperate browser and called anotherMethod > (). > > result: Nothing. Not a sausage :) > > So id say my results are pretty solid. 1 single lonely thread :( > > On Jan 27, 3:17 pm, Shawn Pearce <[email protected]> wrote: >> On Tue, Jan 27, 2009 at 01:42, [email protected] < >> >> [email protected]> wrote: >> >>> I never said it cretaed multiple instances, simply a new thread per >>> request. >> *sigh*. I must not have had enough coffee in the morning before replying to >> your post. I read "thread" as "instance" in your original post. Sorry. >> >>> On Jan 23, 4:30 pm, Shawn Pearce <[email protected]> wrote: >>>> On Fri, Jan 23, 2009 at 08:17, [email protected] < >>>> [email protected]> wrote: >>>>> Standard servlets create a new thread per request but from a few >>>>> simple test i have run this appears not to be the case with GWT. >> Like what everyone else has already said; each concurrent request runs on >> its own thread, but that thread isn't necessarily new. >> >> Most containers recycle threads as thread spin-up/shutdown are relatively >> expensive operations. Pooling threads and recycling them across requests >> reduces the per-request overheads imposed by the container, allowing >> applications to use a larger percentage of the CPU, and the per-request >> latency target the developer is shooting for. E.g. in my latest GWT based >> application, I was trying to hit <200 ms latency. The more of that time >> that is available to the application, the more useful work I can do within >> that window. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
