Domanda

Ho un'applicazione Rails 2.0.2 in esecuzione con un db postgresql. La macchina riceverà i dati su una porta TCP. Ho già codificato un server tcp multithread funzionante per ricevere le richieste, ma ho bisogno di questo codice per funzionare insieme alla mia app Rails.

Quindi credo di dover sapere come estendere un nuovo processo all'interno di Rails o come creare un thread di lavoro che eseguirà il mio loop di server tcp thread. Il mio server tcp ruby ??potrebbe avere accesso ad ActiveRecord, ma non è necessario (posso sempre creare una richiesta http, pubblicare i dati ricevuti sul server Rails originale)

È stato utile?

Soluzione

Perché complicare le cose? Esegui semplicemente le applicazioni - il tuo server TCP e l'applicazione Rails - fianco a fianco.

O tira il livello del modello (e ActiveRecord) nel tuo server TCP (svn :: externals o Piston potrebbe funzionare bene per quello) e lascia che la comunicazione tra le due applicazioni avvenga attraverso il database, o lascia che l'applicazione Rails sia la " ; maestro " e comunicare con esso tramite HTTP come suggerisci.

Per trasformare un'applicazione Ruby in un servizio Windows, vedere la gemma win32-service disponibile dal progetto win32utils : http://rubyforge.org/projects/win32utils/

Altri suggerimenti

Ho bisogno che il server tcp sia eseguito come servizio su un server Windows 2003. Uso mongrel_service per caricare Rails come servizio e non conosco un modo per fare lo stesso per il codice ruby ??puro. Se potessi avviare il mio server tcp all'avvio del computer, esaminerei la tua soluzione (che sembra comunque abbastanza buona).

Non rendere l'app Rails responsabile dello stato dell'app server TCP. In realtà non è molto adatto a farlo - e probabilmente non c'è motivo per cui debbano essere avviati in blocco assoluto l'uno con l'altro. Usa monit o qualcosa per monitorare entrambi i processi del server.

È impossibile dirlo con certezza senza conoscere meglio l'architettura della tua app, ma suggerirei di utilizzare ActiveRecord e il database per comunicare tra i tuoi server anziché HTTP. In questo modo, anche se l'app Rails è inattiva per qualche motivo, l'altro server può comunque elaborare le richieste. Probabilmente sarà anche un po 'più scattante.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top