Forum: Ruby Mongrel "loopback"l request

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
788a2539092e5429d8c546e8ad5084b2?d=identicon&s=25 Peter C. Verhage (Guest)
on 2006-05-26 17:40
(Received via mailing list)
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
1a4f96b06801ac0e30fda3bb0f795313?d=identicon&s=25 Pete Palmer (ppalmer)
on 2006-05-26 17:43
(Received via mailing list)
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
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2006-05-26 17:53
(Received via mailing list)
On Friday 26 May 2006 9:41 am, Peter Palmer 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 Haines
788a2539092e5429d8c546e8ad5084b2?d=identicon&s=25 Peter C. Verhage (Guest)
on 2006-05-26 18:56
(Received via mailing list)
Kirk Haines 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
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2006-05-26 19:24
(Received via mailing list)
On Friday 26 May 2006 10:55 am, Peter C. Verhage wrote:
> Kirk Haines 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 Haines
8c43ed7f065406bf171c0f3eb32cf615?d=identicon&s=25 Zed Shaw (Guest)
on 2006-05-26 19:52
(Received via mailing list)
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.
Ab030a5bfd0d7232b388d3a7449dc84e?d=identicon&s=25 John-Mason P. Shackelford (Guest)
on 2006-05-26 20:35
(Received via mailing list)
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
john-mason.shackelford@pearson.com
http://pearsonedmeasurement.com
788a2539092e5429d8c546e8ad5084b2?d=identicon&s=25 unknown (Guest)
on 2006-05-26 23:09
(Received via mailing list)
> 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.

> 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.

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
This topic is locked and can not be replied to.