[Mongrel] Mongrel woes fixed

Steven Lumos steven at lumos.us
Wed Oct 4 17:50:19 EDT 2006

"Zed A. Shaw" <zedshaw at zedshaw.com> writes:

> On Sun, 1 Oct 2006 21:38:12 +0200
> Jacob Atzen <jacob at jacobatzen.dk> wrote:
>> Hello all,
>> For the past couple of weeks I have been spending some time debugging a
>> couple of issues I was having with Mongrel when I put load on it. I have
>> seen two distinct issues:
>> 1. Mongrel stopped responding as if in an endless loop.
>> 2. Mongrel crashed when severely loaded.
> Cool, glad you took the time to figure this out.
>> I believe to have resolved these two issues and have attached patches
>> which shows the resolution (simple as it is). Explanation of the patches
>> is given below.
>> The first problem is handled by the patch to sync.rb from the standard
>> library. What is happening here is that when sync_unlock is called
>> Thread.critical is set to true. Now if the thread is not the
>> sync_ex_locker an exception is thrown without Thread.critical being set
>> to false. This in turn resulted in a situation where the
>> mongrel_sleeper_thread (configurator.rb:270) was the only thread getting
>> back on the cpu and Thread.critical stayed true. The patch simply
>> ensures that Thread.critical is set to false upon leaving sync.rb.
> Ok, is there a way to fix this without having people backpatch their
> ruby?  Also, why were you the only one having this problem?  I'd
> like to know how the error is caused if you could explain it.

He's definitely not the only one having this problem.  I've been
working on it too as I've had time.  I--and possibly others--have been
wasting time with USR1 trying to figure out what *my* code must have
been doing wrong.  Once I realized that wasn't helping, I had got as
far as commenting out the sleeper thread so that I could get a useful
backtrace, but then it looked like it my query that was hanging.  I
see now that I was stupidly glossing over the most important frame.

thread.rb:100:in `lock'
oci8.rb:126:in `do_ocicall'
oci8.rb:232:in `commit'
(eval):3:in `commit'
active_record/connection_adapters/oracle_adapter.rb:295:in `commit_db_transaction'
active_record/connection_adapters/abstract/database_stateme ...

For people who have this problem, the commonality is likely to be (1)
the Oracle adapter, (2) actions that create threads.  If other (mysql)
adapters don't use threads then that may explain it.


More information about the Mongrel-users mailing list