Ticket #2309
F. Poirotte
First, I'm sorry for posting a message on such an old (closed) ticket,
BUT:
I also got affected by the issue described in this ticket on an
application using TurboGears 2.0. Since in my case upgrading to 2.1 is
not an option (at least for now), I thought I'd simply take against
the patch against 2.1 and apply it on our installation.
I am quite interested in how you fixed the issue, especially since the
ticket was closed as "fixed" without any reference to a particular
revision or indication on the changes involved.
The changelog does not mention this specific issue and the only
revision I could find affecting ToscaWidget's rendering is
http://sourceforge.net/p/turbogears2/tg2/ci/4dca787d5e33a57a8605af634fb55c0c93f1de2d/tree/tg/configuration.py?diff=9624fa8cfcd9b6b18492b915224eb6c675ee0710
which does not relate to this problem AFAICT.
Could you please provide a link to the relevant revision?
Best regards,
François
PS: you trac configuration seems very picky about what it considers "a
potential spam submission" (though I'm aware the project recently
moved to sourceforge, being able to comment on old tickets is still a
good thing).
NiL
this one is tricky, in the .wsgi script called by apache, add these 3
lines at the end. This solved my issue.
import paste.fixture
app=paste.fixture.TestApp(application)
app.get("/")
NIL
F. Poirotte
Thanks for the quick reply.
By any chance, do you know why this is necessary?
That snippet looks like black magic to me and I'd rather have some
strong technical background on this issue before I change the code on
our production servers.
I remember seeing a note somewhere on turbogears website saying that
you may need to "preload" the application in case you use load-
balancing services and such. It that somehow related to the issue at
hand? (we don't use any load-balancing on our servers, so I never gave
any attention to that warning)
François
Christoph Zwerschke
> I am quite interested in how you fixed the issue, especially since the
> ticket was closed as "fixed" without any reference to a particular
> revision or indication on the changes involved.
Just as an aside, I find this also very annoying and appeal to all
developers to always add a proper explanation when closing tickets.
Also, for bug fixes and features, regression tests and doc/changelog
updates are a must.
> PS: you trac configuration seems very picky about what it considers "a
> potential spam submission" (though I'm aware the project recently
> moved to sourceforge, being able to comment on old tickets is still a
> good thing).
The trac will be closed anyway and made read only. All open tickets have
been moved, a link in the last comment should point to the corresponding
ticket on SourceForge, so you can comment there. For closed tickets,
open a new ticket on SourceForge. We will keep the old Trac so you can
still add a reference to the old ticket. It does not make sense and is
not maintainable to have two open issue trackers.
-- Christoph
NiL
I found some more details, but alas I didn't keep the url reference
close to the black magic
something to do with apache lauching several python threads behind
mod_wsgi
I have this in production
I you discover "strong technical background on this issue", please let
us know !
NIL
Diez B. Roggisch
On Apr 1, 2011, at 2:58 PM, F. Poirotte wrote:
> Hi,
>
> Thanks for the quick reply.
> By any chance, do you know why this is necessary?
> That snippet looks like black magic to me and I'd rather have some
> strong technical background on this issue before I change the code on
> our production servers.
>
> I remember seeing a note somewhere on turbogears website saying that
> you may need to "preload" the application in case you use load-
> balancing services and such. It that somehow related to the issue at
> hand? (we don't use any load-balancing on our servers, so I never gave
> any attention to that warning)
The snippet will in fact force the mod_wsgi-process to pre-load the full application controller hierarchy. As a result, all the tosca-widgets should be instantiated, and their resources registered in the resource-middleware.
The reason this needs to be done is because usually, you run mod_wsgi with several processes. Lets name these P1-P10.
Now if a request hits a freshly started apache (without the "magic lines"), it hits P1. That initial request is directed at a controller action, so the full TG2 app with it's controller hierarchy is bootstrapped. All is nice and easy.
The resulting HTML now contains several references to static resources from TW. So the browser will - in parallel - request these. Because P1 is just finished, it probably won't even getting any of these requests. Instead, the are distributed amongst P2-P10.
And these processes are not bootstrapped yet. So, TW doesn't know about any resources when asked, and the result is a 404 or 500.
And for that reason, the "magic snippet" is there.
It is unfortunate, but I don't see any other way. You could try & have some sort of finalizing method-call into the Pylons/TG2-stack that essentially does the same, but the underlying technology won't be changeable.
Diez
F. Poirotte
lot, appreciated.
I guess I'll apply the "patch" soon then.
François