Besoin d'exécuter un serveur TCP en plus d'une application Rails

Question

J'ai une application Rails 2.0.2 qui s'exécute avec une base de données postgresql. La machine recevra les données sur un port TCP. J'ai déjà codé un serveur TCP multithread Ruby opérationnel pour recevoir les demandes, mais j'ai besoin de ce code pour qu'il soit exécuté parallèlement à mon application Rails.

Donc, je suppose que je dois savoir comment étendre un nouveau processus dans Rails ou comment créer un thread de travail qui exécutera ma boucle de serveur TCP threadée. Mon serveur Ruby TCP pourrait avoir accès à ActiveRecord, mais ce n’est pas nécessaire (je peux toujours créer une demande http, poster les données reçues sur le serveur Rails original)

Answer 1

Pourquoi compliquer les choses? Il suffit d’exécuter les applications - votre serveur TCP et l’application Rails - côte à côte.

Soit vous insérez le niveau de modèle (et ActiveRecord) dans votre serveur TCP (svn :: externals ou Piston peuvent très bien fonctionner pour cela) et laissez la communication entre les deux applications se faire via la base de données, ou laissez l'application Rails utilisée. ; maître " et communiquez avec via HTTP comme vous le suggérez.

Pour transformer une application Ruby en service Windows, consultez la gem win32-service disponible dans le projet win32utils : http://rubyforge.org/projects/win32utils/

Answer 2

J'ai besoin que le serveur TCP s'exécute en tant que service sur un serveur Windows 2003. J'utilise mongrel_service pour charger Rails en tant que service, et je ne connais pas de moyen de faire de même pour du code ruby ??pur. Si je pouvais démarrer mon serveur TCP au démarrage de l'ordinateur, j'examinerais votre solution (qui semble néanmoins bonne).

Answer 3

Ne rendez pas votre application Rails responsable de l'état de l'application serveur TCP. Ce n’est vraiment pas très bien fait pour cela - et il n’ya probablement aucune raison pour qu’ils soient démarrés à la limite. Utilisez monit ou quelque chose pour surveiller les deux processus du serveur.

Il est impossible de dire avec certitude sans en savoir plus sur l'architecture de votre application, mais je suggérerais d'utiliser ActiveRecord et la base de données pour communiquer entre vos serveurs au lieu de HTTP. Ainsi, même si votre application Rails est en panne pour une raison quelconque, votre autre serveur peut toujours traiter les demandes. Ce sera probablement aussi un peu plus vif.