>>>> 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.
Okay, thanks for the explanation, indeed signal would not be safe. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
