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.
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.
It’s step b I’m not sure how to implement?
Thanks
Greg
DRB is most likely what you are looking for and Backgroundrb (http:// backgroundrb.rubyforge.org/) is a Rails plugin that makes it easy.
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…
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)?
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 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.
