Necesito ejecutar un servidor TCP además de una aplicación Rails

Question

Tengo una aplicación Rails 2.0.2 que se ejecuta con una base de datos postgresql. La máquina recibirá datos en un puerto TCP. Ya he codificado un servidor TCP de Ruby multiproceso para recibir las solicitudes, pero necesito este código para ejecutarme junto con mi aplicación Rails.

Entonces, creo que necesito saber cómo abarcar un nuevo proceso dentro de Rails, o cómo crear un subproceso de trabajo que ejecutará mi bucle de servidor tcp. Mi servidor ruby ??tcp podría tener acceso a ActiveRecord, pero no es necesario (siempre puedo crear una solicitud http, publicar los datos recibidos en el servidor Rails original)

Answer 1

¿Por qué complicar las cosas? Solo ejecute las aplicaciones, su servidor TCP y la aplicación Rails, lado a lado.

Coloque el nivel del modelo (y ActiveRecord) en su servidor TCP (svn :: externals o Piston podría funcionar bien para eso) y deje que la comunicación entre las dos aplicaciones pase por la base de datos, o deje que la aplicación Rails sea el " ; maestro " y comunícate con él a través de HTTP como sugieras.

Para convertir una aplicación Ruby en un servicio de Windows, consulte la gema win32-service disponible en el proyecto win32utils : http://rubyforge.org/projects/win32utils/

Answer 2

Necesito que el servidor TCP se ejecute como un servicio en un servidor Windows 2003. Utilizo el servicio mongrel para cargar Rails como un servicio, y no conozco una forma de hacer lo mismo con el código ruby ??puro. Si pudiera iniciar mi servidor TCP cuando inicie la computadora, buscaré en su solución (lo cual parece bastante bueno).

Answer 3

No haga que su aplicación Rails sea responsable del estado de la aplicación del servidor TCP. Realmente no está muy bien adaptado para hacer eso, y probablemente no haya ninguna razón por la que deban iniciarse de manera absoluta entre sí. Use monit o algo para monitorear ambos procesos del servidor.

Es imposible decirlo con seguridad sin saber más de la arquitectura de su aplicación, pero sugeriría usar ActiveRecord y la base de datos para comunicarse entre sus servidores en lugar de HTTP. De esta manera, incluso si su aplicación Rails está inactiva por algún motivo, su otro servidor todavía puede procesar solicitudes. Probablemente también sea un poco más rápido.