We have a rails app that makes http calls to a data cloud. The rails
app runs under tomcat. We need to make between 1-3 outgoing http
calls per incoming request to rails. The first requirement is http
keep-alive support, and a secondary goal is parallel requests. So
I’ve been looking at several options most of which involve threads.
#1. Use the apache HttpClient which supports connection pools and
keep-alives. I think it supports parallel requests, can’t remember
for sure.
#2. Use eventmachine and come up with some type of synchronous
interface for making http requests. I’ve used EM a lot in the past,
but mainly in server code. I was thinking of using thread queues to
communicate between the rails threads and an EM thread. How expensive
would it be to start up a thread queue per rails thread? Another
thought is to use zeromq to communicate between the rail threads and
the EM thread. It provides a blocking interface. Fibers would be
cool, but 1.9 support isn’t quite good enough yet for rails, our app
won’t even startup with --1.9 and it fails in rails core, not some
obscure third party gem.
Specifically for using EM, are there other approaches anyone can think
of that might work better?
Chris
On Jun 14, 2011, at 2:19 PM, snacktime wrote:
#2. Use eventmachine and come up with some type of synchronous
interface for making http requests. I’ve used EM a lot in the past,
but mainly in server code. I was thinking of using thread queues to
communicate between the rails threads and an EM thread. How expensive
would it be to start up a thread queue per rails thread? Another
thought is to use zeromq to communicate between the rail threads and
the EM thread. It provides a blocking interface. Fibers would be
cool, but 1.9 support isn’t quite good enough yet for rails, our app
won’t even startup with --1.9 and it fails in rails core, not some
obscure third party gem.
Chris,
this is tailor made for using 0mq and the :inproc transport. You
mentioned that as a possibility so I am just reaffirming it.
I rarely use Queues anymore. 0mq has taken its place.
cr
On Tue, Jun 14, 2011 at 12:27 PM, Chuck R. [email protected]
wrote:
Chris,
this is tailor made for using 0mq and the :inproc transport. You mentioned that
as a possibility so I am just reaffirming it.
I rarely use Queues anymore. 0mq has taken its place.
We are using 0mq with inproc in a limited way already and it’s worked
well so far. It scares me much less then using thread queues. Thanks
a lot for the feedback.
Chris