Is anyone able to clarify how I should, within a controller action, kick off a separate thread prior to finalising the action and rendering back to the browser. What I want to do is:
a- enter action
b- separate thread => Sleep 1 minute, then make HTTP request out to a separate application, no response is really required (this is to simulate a subsequent palpay IPN confirmation in my stub)
c- main action (i.e. don’t wait for the above separate thread to complete for this) - perform neccessary steps and then render response back to browser.
thanks for the pointer Bryan - it seems somewhat a heavy weight solution for my seemingly simple requirement, however I guess if Ruby in general can’t handle a “fork” concept perhaps it is just as easy to install this plugin and use it…
Nothing to do with Ruby; ruby forks just fine. The problem is that
your parent process can't get on with the next HTTP request with an
unreaped child out in the wild.
In other words, this is an issue with the design of Rails (and many
web frameworks in general), not Ruby.
Try ask this question on a J2EE forum and see what you get.
hi Sheldon - actually this might explain a timeout I was experiencing yesterday where I was creating a call from App A=>B, but then B was trying to do a separate confirmation (a 2nd HTTP request) back to A (a separate confirm action that A has) prior to finishing up in the controller action then rendering back to App A.
I don’t quite understand where the blocking bottleneck occurs. If the rails action can spawn a new rails process which then itself creates a new HTTP request wouldn’t this be OK? Looking at the APIs the HTTP stuff seems to be in the Ruby Standard Library no (not the Rails API)?
I think you'll benefit enormously from the following mantra:
Multiple threads and processes in a single request handler are
illegal.
It's not true, but it'll save you a whole lot of pain.
If your second request can reasonably be completed in the context of
this request, just handle it inline.
If not, store the details of the request in the database and handle
the processing thereof in a runner out of cron, or using one of the
fun work distribution mechanisms.
I remember seeing a very slick "clustered batch job manager", but
forget its name and now can't find it with Google.
But anyway, the point is, stick to a single thread per request handler
for a good time.
