Mongrel "loopback"l request

Ruby
1

Hi,

I’m using mongrel (the mongrel_rails wrapper to be exact) for a SOAP
server. One of the possible SOAP requests can trigger a Net::HTTP get
request to the server itself. At that time the complete server seems to
block. I suspect this has something to do with Ruby’s non-native
threads, but I don’t know of a way to workaround this. Any suggestions?

Thanks,

Peter

2

Peter C. Verhage wrote:

Peter
Hi,

This is because Mongrel ( I believe ) is single threaded. As it is
currently running your request before it makes the SOAP call, the soap
call will block, which of course will block your app too - causing dead
lock. Not much you can do about this apart from setting up a cluster
afaik.

Cheers,

Pete

3

On Friday 26 May 2006 9:41 am, Peter P. wrote:

This is because Mongrel ( I believe ) is single threaded. As it is
currently running your request before it makes the SOAP call, the soap
call will block, which of course will block your app too - causing dead
lock. Not much you can do about this apart from setting up a cluster afaik.

Mongrel is not single threaded, but the Rails handler is because Rails
is not
thread-safe.

This is out of 0.3.12 because that’s the code I have immediately handy,
but…

@guard.synchronize do

Rails is not thread safe so must be run entirely within synchronize

Dispatcher.dispatch(cgi,
ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS, response.body)
end

Kirk H.

4

Kirk H. wrote:

Mongrel is not single threaded, but the Rails handler is because Rails is not
thread-safe.

But doesn’t this then mean Mongrel is only capable of handling one Rails
request at at time? I just checked btw, when I use webrick I’m facing
the same problem.

Regards,

Peter

5

On Friday 26 May 2006 10:55 am, Peter C. Verhage wrote:

Kirk H. wrote:

Mongrel is not single threaded, but the Rails handler is because Rails is
not thread-safe.

But doesn’t this then mean Mongrel is only capable of handling one Rails
request at at time? I just checked btw, when I use webrick I’m facing
the same problem.

Maybe I am splitting hairs here, but Mongrel itself can handle X numbers
of
requests at the same time. Rails can not. The Rails handler for
Mongrel
synchronizes requests to Rails. So yes, the net effect is that while
multiple requests can be recevied by the Mongrel/Rails process
simultaneously, they are handled in serial fashion, which results in a
deadlock when one request initiates a subrequest to the same server. It
is a
Rails issue, though, not a Mongrel one, to be specfic, and one that, I
would
guess, doesn’t come up too often since most people aren’t making
subrequests
to the same server in their request handling.

To work around it, you either need to have an architecture where you
have
multiple mongrel/rails backend processes that requests get distributed
to, or
someone needs to write something like an SCGI handler for mongrel to let
a
single mongrel webserver communicate with multiple Rails backends.
Anyone
have any other ideas?

Kirk H.

6

Hi Peter,

On Sat, 2006-05-27 at 00:38 +0900, Peter C. Verhage wrote:

Hi,

I’m using mongrel (the mongrel_rails wrapper to be exact) for a SOAP
server. One of the possible SOAP requests can trigger a Net::HTTP get
request to the server itself. At that time the complete server seems to
block. I suspect this has something to do with Ruby’s non-native
threads, but I don’t know of a way to workaround this. Any suggestions?

Everyone else has already told you what’s going on with Rails locking,
so I’ll just throw out a couple of solutions.

  1. Try out mongrel_cluster as a way to easily manage a bunch of
    mongrels. With more than one Mongrel running you’ll be able to do this
    no problems. Well, see below.
  2. This guy walks into the doctor’s office and says, “Doc, it hurts when
    I do this.” Doctor says, “Well, don’t do that.” Seriously, if you have
    a situation where you’re doing SOAP calls back to the same process I
    think you’ve got to rethink your SOAP usage. It’s horribly inefficient
    and leads to all sorts of other problems. If you’re just doing this
    during development then run two mongrel servers. But in production this
    is a sign that you’ve got the design wrong.

#2 isn’t a dodge around the threading issue. You might have legit
reasons to use SOAP as a replacement for (), but in every case where
I’ve seen SOAP used this way I’ve found that it was gratuitous and that
a much simpler design was possible.

Good luck.

7
  1. Try out mongrel_cluster as a way to easily manage a bunch of
    mongrels. With more than one Mongrel running you’ll be able to do this
    no problems. Well, see below.

I will look into this, thanks.

  1. This guy walks into the doctor’s office and says, “Doc, it hurts when
    I do this.” Doctor says, “Well, don’t do that.” Seriously, if you have
    a situation where you’re doing SOAP calls back to the same process I
    think you’ve got to rethink your SOAP usage. It’s horribly inefficient
    and leads to all sorts of other problems. If you’re just doing this
    during development then run two mongrel servers. But in production this
    is a sign that you’ve got the design wrong.

I simplified the use case for my posting but the real use-case is
somewhat
different. The SOAP method in question tries to synchronize with a
certain
RSS/Atom feed. This feed can be specified by the caller. However there
is
also another SOAP call that is used for an RSS feed. It’s possible to
specify this feed when you call the first method. I can’t detect this
particual case and do it locally because the feed in question is handled
by a PHP script which does the SOAP calls. Come to think of it, it even
sounds more complex now which doesn’t seem to help my case. :wink:

But I hoped one Mongrel instance could handle multiple Rails requests in
parallel out of the box. Unfortunately it doesn’t, but that’s no problem
I
will work around it.

Thanks for the help all.

Regards,

Peter

8

Unless I misunderstand the source–or unless it is lying or has
changed recently–rails IS thread safe though a rails application
may not be.

See:

//root/trunk/actionpack/lib/action_controller/base.rb

lines 257-261

Controls whether the application is thread-safe, so multi-threaded servers like WEBrick know whether to apply a mutex

around the performance of each action. Action Pack and Active Record are by default > thread-safe, but many applications

may not be. Turned off by default.

@@allow_concurrency = false
cattr_accessor :allow_concurrency

–
John-Mason Shackelford

Software Developer
Pearson Educational Measurement

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
[email protected]
http://pearsonedmeasurement.com