Daniel Fetchinson schrieb: >>> When a request comes in a tg app will access all sorts of remote/local >>> services like db, etc. These might take very long to complete >>> occasionally due to high traffic, local disruptions, etc. and let's >>> suppose these disruptions are only temporary. So if they happen we >>> have every reason to believe that after a few seconds the services >>> will be available again. >>> >>> I'd like to have a general mechanism for handling this and returning a >>> short page to the user saying "services temporary unavailable, please >>> try again in a few moments". Since I wouldn't want to handle every >>> service separately I thought it would be handy to be able to say "if >>> the controller doesn't return the response dict in 5 seconds, let's >>> send the warning page". What would be the way to instruct tg 1.x to do >>> this? I thought about a decorator for the exposed methods, or are >>> there better solutions? Maybe others have already come up with >>> something better and/or more elegant. >> I doubt this can be done with "pure" TG1, as this is a concurrent thing to >> determine. > > What do you mean by 'concurrent thing to determine'?
You need concurrency, read threads. >> The only option I see is to use a proxy that has a timeout when >> waiting for the socket to retrieve the downstream data, and then redirect to >> that page of yours. > > I think it's possible to have a timeout decorator that will simply > count the given number of seconds and if that passes, abort the > callable. Whether the callable is busy with a socket or anything else, > is irrelevant. > > I'm thinking along the lines of > > http://code.activestate.com/recipes/307871/ > http://pypi.python.org/pypi/timeout > > which both only use the signal module to achieve this. I'm not very > familiar with this module so I'm not sure what the side effects are in > a multithreaded environment like wsgi/tg/apache/etc. AFAIK they don't play nice with multiple threads. They rely on global state (the sigalarm is set *per process*), and signal has thread-issues: """ the main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads). This means that signals can’t be used as a means of inter-thread communication. Use locks instead. """ (from the docs) > > You think this would not work with tg 1.x in general? > Or you think that it would not work with some of the deployment > options in particular? Well, if you don't use threads, you stand a chance, but this more or less implies apache (or maybe some other HTTP-server, dunno) - and then you can use mod_proxy, which I'm not 100% sure but might already have that timeout-stuff. But "pure" TG1 - nope, don't see that happen. Besides, I don't find the usecase to compelling either. We have a static "maintenance"-site up, and that's it. Anything else is essentially masking some troubles you shouldn't have in the first place, and for that a simple 500-redirect should suffice IMHO. Diez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
