A few comments. On Feb 24, 1:56 am, sevenseeker <[EMAIL PROTECTED]> wrote: > from another thread: > Only restriction is that TG must run within a single process. If > running TG in mod_wsgi daemon mode with a single process that is not a > problem. > > This reminds me of a question I have frequently: > What recommendations is there for debugging TG when it is not > contained within a single process?
If you are using older TG with SQLObject then running it as a multi process application using either Apache, or with lots of backends and mod_proxy distributing to them, is not necessarily an option anyway. This is because SQLObject has issues with database cache flushing (or something like) that, which means that views in data in different processes may not be consistent, with some processes seeing older data. Thus, you would need to be using SQLAlchemy for multi process to be an option to begin with. > As for TG1 I have not done ANYTHING related to WSGI and suppose it is > time to check into that. > > Is the solution for debugging to keep everything within a single WSGI > process? The issue with multi process is that within context of Apache at least, you can't have standard input being used by multiple processes. This therefore prevents use of interactive debuggers like pdb unless you force Apache to run in single process debug mode. See section 'Python Interactive Debugger' of: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques If running multiple distinct TG instances behind mod_proxy, with each TG instance started up independently, then each will have its own standard input, but then the problem is how do you ensure that a request goes to the process which you have attached to for debugging, as mod_proxy will randomly choose one. For any sort of browser based debugger, a similar issue exists, in that the server side code needs to maintain state between distinct HTTP requests. As a result, subsequent requests must go back to the same TG process. If running multi process this isn't guaranteed. Now it may be that the case that the system used to distribute requests across the processes has a means of implementing sticky sessions. That is, for a specific session ensure that requests go back to same process in a set of processes. Although this might technically be achievable, I know of no browser based debugger that makes use of any such feature where a hosting setup may support it. So, all up use of a single process when doing debugging is probably preferable. Graham --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
