2011-03-24 6 views
0

J'ai donc un procss d'arrière-plan que j'ai besoin d'exposer/contrôler en tant que service web. J'ai enveloppé le processus pour être en mesure d'accepter les commandes via un tuyau, mais maintenant j'essaie de savoir comment le contrôler.Python: DJango comment posséder un processus de longue durée?

Les exigences sont les suivantes:

  1. besoin d'être en mesure de démarrer le processus via le web
  2. doivent être en mesure d'envoyer cmds
  3. doivent être en mesure de retourner des résultats de cmds
  4. Le processus une fois démarré est en vie jusqu'à ce qu'il soit tué

Je pense que la question principale est comment puis-je obtenir le processus django? Propre dans le sens, garder un valide enregistrer le tuyau pour la communication future avec le processus d'arrière-plan. En ce moment est quelque chose le long des lignes (juste un exemple):

if __name__ == '__main__': 
to_process_pipe, process_pipe = Pipe() 
node = PFacade(process_pipe) 
p.start() 

to_process_pipe.send(['connect']) 
print to_process_pipe.recv() 

p.killed = True 
p.join() 

Je pense que je besoin d'une meilleure façon de pouvoir communiquer, bc Je ne sais pas comment je pourrais stocker le tuyau dans django.


Et s'il vous plaît, si vous allez répondre à l'utilisation Céleri, s'il vous plaît donnez-moi une bonne explication de comment.

+0

Vous ne voulez jamais que Django le possède, car vous ne pouvez pas nécessairement savoir combien de processus Django vous allez exécuter. –

+0

Oui, je suis en train de remplacer le tuyau avec une queue de céleri, je ne savais pas s'il y avait un meilleur moyen. – Nix

Répondre

0

Ma solution finale était d'écrire une "boîte aux lettres" personnalisée basée sur pidbox.Mailbox. Leur implémentation était horriblement brisée mais l'algorithme était solide.

J'ai fondamentalement mis en place une API REST hébergée via django, puis j'ai demandé à cette API d'envoyer un message à une file d'attente AMQP (implémentation QPID).

J'ai eu alors un processus qui se trouve, surveille les files d'attente, et passess le long des commandes comme ils sont venus.

Il a bien fonctionné et était assez impressionnant quand il est venu ensemble.

-1

Peut-être que Celery (file d'attente de tâches asynchrone/file d'attente de travail basée sur le passage de message distribué) correspond à votre facture.

+0

Je l'ai dit explicitement, si vous allez dire céleri, s'il vous plaît donnez-moi un bon exemple de production. – Nix

+0

Désolé, j'ai manqué cette ligne. – jammon

0

ok, donc vous voulez qu'un processus soit opérationnel et accepte les commandes des django workers?

Dans un tel cas, le céleri ne sera pas une bonne solution car il ne fournit pas de communication après que la tâche a été créée. IMHO une bonne solution sera d'avoir un deamon (implémenté comme commande de gestion de django) avec une boucle principale infinie, certains dormant entre les exécutions, écoutant les commandes de la file d'attente spécifique.

Pour la communication - kombu/django-kombu sera super (c'était une partie de céleri).

+0

Pouvez-vous expliquer ce que vous voulez dire par «il ne fournit pas de communication après la création d'une tâche» – Nix

+0

car lorsque la tâche est déjà en cours, il n'y a pas de méthode de communication * définie *. Céleri est conçu pour les tâches (donc commencer quelque chose et finir) pas pour les démons de regroupement qui reste pour toujours et par exemple. commencez-les quand ils vont mourir. – Jerzyk

+0

Comment gérerions-nous la requête/réponse avec kombu? Serions-nous juste en train de faire reply_tos? – Nix

Questions connexes