Sorry I wasn't clearer in my earlier post. The reason I wanted you to kill all of the FastCGI processes and then wait for 15 minutes was to make sure that you didn't have a rogue process contributing to your difficulties.
Usually, only one "pkill tg_fastcgi.fcgi" command is needed to tell all of the processes that a new version is available. Your changes should immediately be picked up after issuing that directive; no need to wait for 15 minutes.
Also, do not use the autoreload.package configuration in production because CherryPy won't run properly under the FastCGI setup.
Sorry for the confusion.
Sean
On 2/19/06,
Vladimir Blagojevic <[EMAIL PROTECTED]> wrote:
Eric, Sean,
thanks for your posts. I don't find the crontab to be a real problem. I
mean, it would be nice for the thing to work out of the box, but as
long as there is a solution.
The redirects bother me more. They don't seem to work. I refactored the
code now to have less redirects. I guess it's a good idea anyway since
those go through the FastCGI and have performance impact. The
application works better now, but I am still not happy with the speed.
But what I find to be a real problem is the deployment of new versions.
I don't think it's acceptable that one needs to bring down the web site
down for up to 15 minutes (time it can take for FastCGI to restart)
every time they want to deploy a new version.
This is one of the reasons why I like web applications - that all your
users have one and only one version of your code, and that you can
easily deploy new versions any time.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
