I am writing a service that should handle HTTP requests according to following scenario:
- register a job - make an "ok" response - do the job - report the job is complete by making HTTP request to other service The jobs are often lightweight and will be executed very quickly so I don't want to use cron-based solutions or queue services - both that ways are adding too much overhead for such a task. As far as I know, there is no way (at least no right and easy way) to use the thread after response was sent. (or maybe I'm wrong here?) So I'm going to start a new daemon thread to do the job. And my scenario will look like: - register a job - start a new daemon thread for job processing - make an "ok" response -- daemon thread will (somewhen) report the job is complete by making HTTP request to other service I'm going to do it using a regular threading.Thread with setDaemon (True) Is it a reasonable solution? Are there any hidden dangers in it? Will it work perfectly with any deployment way? (mod_python, mod_wsgi, FastCGI) --~--~---------~--~----~------------~-------~--~----~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
