# Mongrel "loopback"l request **URL:** \ **Category:** Ruby\ **Created:** [May 26, 2006, 5:40pm UTC](https://www.ruby-forum.com/t/mongrel-loopback-l-request/61731 "2006-05-26T17:40:17Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Peter\_CSVerhage](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ea924/32.png) [@Peter\_CSVerhage](https://www.ruby-forum.com/u/Peter_CSVerhage)\ **Post date:** [May 26, 2006, 5:40pm UTC](https://www.ruby-forum.com/t/mongrel-loopback-l-request/61731/1 "2006-05-26T17:40:17Z")
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 ---
**Author:** ![Peter\_CSVerhage](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ea924/32.png) [@Peter\_CSVerhage](https://www.ruby-forum.com/u/Peter_CSVerhage)\ **Post date:** [May 26, 2006, 5:43pm UTC](https://www.ruby-forum.com/t/mongrel-loopback-l-request/61731/2 "2006-05-26T17:43:36Z")
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 ---
**Author:** ![Peter\_CSVerhage](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ea924/32.png) [@Peter\_CSVerhage](https://www.ruby-forum.com/u/Peter_CSVerhage)\ **Post date:** [May 26, 2006, 5:53pm UTC](https://www.ruby-forum.com/t/mongrel-loopback-l-request/61731/3 "2006-05-26T17:53:10Z")
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. ---
**Author:** ![Peter\_CSVerhage](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ea924/32.png) [@Peter\_CSVerhage](https://www.ruby-forum.com/u/Peter_CSVerhage)\ **Post date:** [May 26, 2006, 6:56pm UTC](https://www.ruby-forum.com/t/mongrel-loopback-l-request/61731/4 "2006-05-26T18:56:09Z")
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 ---
**Author:** ![Peter\_CSVerhage](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ea924/32.png) [@Peter\_CSVerhage](https://www.ruby-forum.com/u/Peter_CSVerhage)\ **Post date:** [May 26, 2006, 7:24pm UTC](https://www.ruby-forum.com/t/mongrel-loopback-l-request/61731/5 "2006-05-26T19:24:59Z")
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. ---
**Author:** ![Peter\_CSVerhage](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ea924/32.png) [@Peter\_CSVerhage](https://www.ruby-forum.com/u/Peter_CSVerhage)\ **Post date:** [May 26, 2006, 7:52pm UTC](https://www.ruby-forum.com/t/mongrel-loopback-l-request/61731/6 "2006-05-26T19:52:33Z")
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. ---
**Author:** ![Peter\_CSVerhage](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ea924/32.png) [@Peter\_CSVerhage](https://www.ruby-forum.com/u/Peter_CSVerhage)\ **Post date:** [May 26, 2006, 11:09pm UTC](https://www.ruby-forum.com/t/mongrel-loopback-l-request/61731/7 "2006-05-26T23:09:20Z")
> 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. 😉 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 ---
**Author:** ![Peter\_CSVerhage](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ea924/32.png) [@Peter\_CSVerhage](https://www.ruby-forum.com/u/Peter_CSVerhage)\ **Post date:** [May 26, 2006, 8:35pm UTC](https://www.ruby-forum.com/t/mongrel-loopback-l-request/61731/8 "2006-05-26T20:35:24Z")
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 removed\_email\_address@domain.invalid [http://pearsonedmeasurement.com](http://pearsonedmeasurement.com)