Hmm, this sounds contrary to what Massimo and Jonathan have been saying. >From their explanations, it sounds like user A should not be blocking user B (i.e., their requests should not be sharing a thread). On Wednesday, January 19, 2011 9:50:35 AM UTC-5, ae wrote:
> > > On Jan 19, 9:17 am, Anthony <abas...@gmail.com> wrote: > > On Wednesday, January 19, 2011 8:18:25 AM UTC-5, ae wrote: > > > > > I have lots of users and when one thread takes a long time, some users > > > can keep accessing controller functions and some can't. Once the long- > > > > running controller finishes, everyone can access stuff again. > > > > Are you saying that when user A hits a long-running controller (action), > > that sometimes blocks user B (who is presumably using a different > machine) > > from accessing the application? Is this just a thread starvation issue? I > > > assume user B wouldn't be affected by user A unless there just aren't any > > > available threads left to service B's request, no? > > Possibly. If you have many threads, then B is unlikely to be assigned > to the same thread as A and the behavior won't be exhibited. > > Configure web2py with just two threads and open a few browsers using > different profiles (they each have to have unique cookies). They can > be on different hosts or not (My office-mate and I each have a desktop > and a laptop--we tested this together). > > As for thread starvation, I'd say no. The host running web2py is an 8- > core machine that's mostly idle. I've also tested this on my desktop > (4-core) which was also mostly idle. Also, the 'blocking' in the long > running function is just a call to sleep() and in the production > environment it's a connections to other hosts that block; they return > small (<1k) strings. Lastly, if it were thread starvation, then I > would expect that no user could do anything. For users who /can/ > access the app, performance is normal. > > It's easy to test this (but once more: Rocket might be different). > >
