Thanks Graham and Ben for the prompt feedback. It was most helpful. > Depending on the hosting mechanism has been configured, any Django > startup may only happen the first time a request comes in. This would > potentially delay requests if the initialisation takes a while.
Our current hosting intent is Apache per the current configuration recommendations. Unfortunately, I'm not familiar with Arache/mod- Python so I'm on unknown ground. Initialization time is not an issue as the system as a whole takes a few minutes to come up as multiple servers and daemons are involved. If I understand your feedback properly, it sounds like startup.py isn't processed until the first time Django is tickled. That being the case it would appear sensible to have something external to Django/Apache post to a URI to cause initialization. Does this seem reasonable? > > Part of the application involves running an external application on a > > scheduled basis. > > Apache is a multiprocess web server. Does it matter that your request > is going to only one of the possible many processes which may be > running? Hmmm. I'd not considered that. Part of the requirement here is that one and only one of these scheduled things be running at a time. The tentative approach is to queue the cron generated items for later consumption by a separate process. That being the case, it appears that I don't really care what process services the cron URI. Thanks for pointing it out. Do I understand correctly from your feedback that there may be many Django processes running within Apache/mod-Python? > Do note it is possible to write standalone scripts that import your > Django instance and thus allow you to do stuff on the database outside > of the context of an Apache process. Can you give me a pointer? > > What, if any, issues are there with a daemon like process running > > within Django/Apache? > > Do you mean a daemonised thread running in Apache processes? Running > Django under Apache is not an issue, so not sure if you mean something > else. I didn't explain myself very well here. The application needs to maintain a work queue. Work arrives via URI post and is enqueued to a work queue. When work arrives the python method that processes the work queue needs to be started if necessary. It dequeues work items in turn and performs them. The work involves either sending a URI to another web service to cause the work to happen or executing an external application such as RSYNC. In either case progress needs to be monitored and recorded. The current approach is to start the method that consumes the work queue and let it run indefinitely. Since I'm unfamiliar with Django/Apache/mod-Python I'm uncertain of what, if any, issues this approach has. > There is unfortunately no definitive answer to that. Although people > use Django on Apache winnt and worker MPMs, plus with multithreaded > fastcgi configurations, there is no guarantee that Django is thread > safe. Thanks. > You may perhaps want to split out any long running activities from the > Django processes running in Apache into a separate backend server > independent from Apache. That backend process can be a true long > running process, where as with processes under Apache, they can be > recycled by Apache which may be an issue where an activity is > interrupted. We are using that approach in one part of the system already and considering it for dealing with the work queue. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
