On 31 Dec 2012, at 10:36 AM, HittingSmoke <hittingsm...@gmail.com> 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.
--
