Communication between server-side Ruby process and client Javascript

Question

Context

• I have an app that does time-consuming processing of texts in Ruby.
• When a users submits a text, a background process is forked to take care of that text.
• This process continuously outputs new parts of the text as they have been processed.
• Meanwhile, the user is redirected to the page where the processed text will be output.

My question is: how can the client's Javascript communicate with a process running on the server, given its PID? Is that possible? Do I need to wrap each background process inside its own servlet running on its own port?

Answer 1

It cannot access the process space. You need an HTTP interface to do this. You could use long polling to do this. The server could output text at regular intervals and the client side script could long poll it.

Check out the long polling example here: How do I implement basic "Long Polling"?

Answer 2

Consider using websockets. In my Zend application I have written a proxy script which sends packets to JS. The other approach it to make setTimeout which asks http server every x seconds if the process had finish.

Answer 3

The simplest way would be to use Pusher or PubNub or similar, so you can push code to a channel containing the PID, and the client can subscribe to the same channel. This way you don't need to set up an HTTP app.

Answer 4

Here is the strategy I ended up using:

• Create a small Sinatra servlet to manage the different jobs.
• Each job request received is assigned a job ID and started in a detached forked process.
• The forked process sets up a DRb service with an array that is used as a stack.
• It then performs a "GET" request on the servlet that associates the job ID with the DRb URI.
• As the process continues execution in the background, it adds elements to the stack.
• The main thread can be polled to return the next element in the stack.
  • Connection to the remote array is established within the servlet, and an element is shifted from the stack.
  • Polling continues until there are no more elements to add on the stack and no more elements to return to the client.
• When the stack is empty, the process terminates.

Any thoughts?