I'll re-enable the router and keep a closer eye on things when restarting uWSGI.
The process hopping sounds right. I run uWSGI with six workers so there are six processes balancing load. The next time it happens I'll restart with a single worker and see if the inconsistency on page load is still present. I know I've had an issue once or twice with uWSGI not shutting down properly and web2py getting confused as to which instance to use causing errors. I tracked that down to a misstep in my install/stop script though. The symptoms are similar though, albeit different errors. On Monday, December 31, 2012 11:00:19 AM UTC-8, Jonathan Lundell wrote: > > On 31 Dec 2012, at 10:36 AM, HittingSmoke <[email protected]<javascript:>> > wrote: > > I've been seeing this over the past week or so since I > started separating my apps into subdomains using the parametric router. My > entries are simple: > > routers = dict( > BASE = dict( > domains = { > 'domain.com' : 'blog', > 'chat.domain.com' : 'chat', > 'maps.domain.com' : 'maps', > } > ), > ) > > The problem is sometimes when calling the function of a non-default > controller it will try to run the controller as a function of default, > giving me an invalid function error. If I focus on the address bar and just > keep hitting enter eventually the server will get it right and route me to > the correct controller and function. If I keep reloading the page it will > eventually break again going back to the default controller. It's > completely random. Sometimes it goes back and forth from broken to working > fairly quickly. Sometimes it breaks for minutes at a time. Sometimes it > works fine for minutes at a time. > > A practical example: > > I set up the controller `new` in my blog app with a function specific to > creating a new blog entry via CRUD. When I got todomain.com/new/blog I > get the error: > > *Invalid Function (/default/new)* > * > * > I did an experiment and tried to call and invalid function on the correct > controller (/new) and indeed it switched between telling me that > /new/fakefunction and /default/new were invalid functions. > > This behavior is quite unpredictable as to when it will pop up. Sometimes > a new controller will not work right away. Sometimes a new controller will > work fine. There are no correlating circumstances I can find. Reloading the > router via Admin does not seem to help, nor does restarting uWSGI. I'm > running web2py through uWSGI which is using my host's shared Nginx instance > as an http proxy to save RAM if that's relevant. > > Currently I'm running without a router as I'm quite a ways off from > production so it doesn't matter. The issues does not show up without > routes.py present. I've searched a bit and I seem to see others with > possibly similar issues but I've seen no conclusive fixes. > > > In your environment (and in most production environments), reloading the > router via admin can be expected to result in the symptom you're seeing. > The problem is that web2py is running in multiple processes, and only one > of them sees the reload command. > > A side note: ordinarily it's not necessary to reload your routes when you > haven't changed routes.py. But there are two exceptions. If routes.py is > using applications=ALL (the default) or controllers=DEFAULT (also the > default) and you change (respectively) the applications subject to routing, > or the controllers in an application subject to routing, you're effectively > changing the router's list of applications or controllers, which it > establishes at load time. So those options (ALL/DEFAULT) are the same as > having an explicit list of applications or controllers in routes.py, and > changing them is equivalent to changing routes.py. > > You'll see correct behavior for requests handled by processes that have > reloaded routes.py, and incorrect behavior otherwise. In your example, the > un-reloaded router tried to route to /default/new because it hadn't seen > blog/controllers/new.py yet. > > One other thing, which IIRC isn't documented, but should be: if the > uncompiled controller files are not present (that is, your installation has > only the compiled versions), then you cannot use controllers=DEFAULT; you > must list the controllers explicitly. This is because the router gets its > list of valid controllers by looking at *.py in your app's controllers > directory. > > So: why do you also see the problem when you restart uwsgi? I can think of > two reasons. One is that you might be misinterpreting the evidence; it's > easy enough to get confused with different possible reasons for the > symptoms. The other is that uwsgi might not be behaving as we might expect > (I don't know anything about it myself). It's critical that all your web2py > processes be restarted for a routes change to work right. > > My suggestion: record all web2py PIDs before and after a uwsgi restart, > and make sure you have a completely new set. If you're still seeing routing > misbehavior, we can investigate further. > --
