My appologies jason, you were correct. I totally forgot about max connections per browser.
So it would appear that my servlet is multi theaded after all and as a result, not thread safe :) Maybe this should be added to the GWT docs as this is something that i feel could be very easily overlooked. On Jan 28, 6:25 am, Jason Morris <[email protected]> wrote: > 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.- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
