How to efficiently implement a blocking call with Rails, while letting the client wait for the reply.

Question

We have a web service written in Rails. The API is published and we cannot change it. Our app communicates with a remote web service that sometimes hangs or takes several seconds to reply.

 Client -> Our Web Service -> Remote Web Service

Currently, if the remote web service hangs for 5 seconds, one of our rails processes on our web service also hangs with it, which is what we need to avoid.

I've seen things such as mod-x-sendfile, modporter, and delayed jobs, but the best I can tell, they all assume the client is not waiting for an answer. Since the API is already established, we cannot tell the client "I'm attempting to do what you want, check back later for the answer."

The best option we have come up with so far is to add a second, non-rails web server running eventmachine to process these particular calls. Is there a better way?

Answer 1

I don't understand what you want here. At the start, you seem to be asking how to make your blocking remote call non-blocking, but then you state that you want the customer to be blocked until the call returns. I am not sure you can have it both ways.

Why not just dump the blocking call off to something like delayed jobs and then send the answer back to the user using AJAX. Or just do the whole call via AJAX. At least, for the user, this will remove the page refresh and having them stare at a blank page for 5 or 10 seconds.

Answer 2

Hi, if you offload the job to delayedJobs or eventmachine, your webserver can continue working. Then to make sure the client does the busy-wait (is blocked) you could use ajax/javascript and check some url to see whether the job has been done. Supposing that upon succesfull completion you set or change something so a result can be shown.

An alternative approach is to use juggernaut to push the result back to the client.