If you make a request, using urllib.urlopen, from your web server back to the same server, it appears to time out. I'm guessing this is something about a single-threaded execution model, though even then I thought there were patches applied to handle this case with sockets.
(In reply to Ian Bicking (:ianb) from comment #0) > If you make a request, using urllib.urlopen, from your web server back to > the same server, it appears to time out. > > I'm guessing this is something about a single-threaded execution model, > though even then I thought there were patches applied to handle this case > with sockets. Can't say for sure, I guess it depends on the execution framework you use in the back-end, but, yes if your WSGI app is single-threaded, you have an issue. Have you tried increasing the number of instances of your app with something like: $> vmc instances appname 4 And trying again ? CloudFoundry lets you scale out your app by running multiple instances of it. But even then, it sounds like your app/framework needs some fixing to be able to handle more than just a few concurrent connections...
A WSGI app doesn't itself include any specific concurrency model, that's the responsibility of the container (gunicorn, as configured by CloudFoundry). I wonder if it's a gunicorn configuration problem? gunicorn is also used by Services in their deployments. Tarek: do you know any configuration parameter that would make recursive HTTP requests work or not with an app under gunicorn? When I try "vmc instances seeitsaveit 4" I get a Not Authorized error.
I'll check the generated gunicorn config. For the vmc instances, your login ticket probably expired, have you tried logging back into vmc first? $> vmc login
vmc login worked, and increasing the instances to 4 did fix the recursive request problem.
No I don't think there's anything like this in gunicorn.
You need to log in before you can comment on or make changes to this bug.