Need to run a TCP server besides a Rails app

Question

Hi,

I have a Rails 2.0.2 application running with a postgresql db. The machine will receive data on a TCP port. I already have coded a working ruby multithreaded tcp server to receive the requests, but I need this code to run alongside my Rails app.

So I guess I need to know how to span a new process inside Rails, or how to create a worker thread that will run my threaded tcp server loop. My ruby tcp server could have access to ActiveRecord, but it's not necessary (I can always create an http request, posting the received data to the original Rails server)

Answer 1

Why complicate things? Just run the applications -- your TCP server and the Rails application -- side by side.

Either pull the model tier (and ActiveRecord) into your TCP server (svn::externals or Piston might work well for that) and let the communication between the two applications happen through the database, or let the Rails application be the "master" and communicate with it via HTTP as you suggest.

To turn a Ruby application into a Windows service, see the win32-service gem available from the win32utils project: http://rubyforge.org/projects/win32utils/

Answer 2

I need the tcp server to run as a service on a Windows 2003 server. I use the mongrel_service to load Rails as a service, and I do not know of a way to do the same for pure ruby code. If I could get my tcp server started when the computer boots, I will look into your solution (which seems pretty good nevertheless).

Answer 3

Don't make your Rails app responsible for the state of TCP server app. It's really not very well-suited to doing that -- and there's probably no reason that they need to be started in absolute lock-step with each other. Use monit or something to monitor both server processes.

It's impossible to say for sure without knowing more of your app architecture, but I'd suggest using ActiveRecord and the database to communicate between your servers instead of HTTP. This way, even if your Rails app is down for some reason, your other server can still process requests. It'll also probably be a bit snappier.