Forum: Ruby Mongrel Web Server 0.3.12.3 -- Thread Tracking and Debugging

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.
Zed S. (Guest)
on 2006-04-06 17:17
(Received via mailing list)
Hello Everyone,

Mongrel is getting closer and closer to being a rock solid release.  My
goal
is to release 0.4 as "production ready" by Canada on Rails.  Please
report
any problems or suggestions you have.  There won't be any major features
or
improvements just fixes and code reviews to repair any found bugs or
security concerns.

People interested in Mongrel should look at
http://mongrel.rubyforge.org/
and remember, you can report bugs by clicking on the two yellow beetles.
You don't have to join the mailing list as I actively check that bug
posting
system.

You can get Mongrel using:  gem install mongrel


CONTENT_TYPE FIX

If you had garbage file uploads than this release is for you.  This
release
has a small fix for a big problem where people uploading files or using
multipart forms would not receive the CONTENT_TYPE and get garbage in
their
request parameters.

Turned out to be a four character fix.  I hate that.


THREAD DEBUGGING

This release also adds a few things to help people debug their use of
threads within their Ruby on Rails applications.  When you run
mongrel_rails
with the -B (debugging) option Mongrel will report all active threads
between each request to log/mongrel_debug/thread.log.  If you see
reports of
Mongrel being overloaded, threads getting killed, or having to wait for
Mongrel to shutdown then turn on debugging (-B) and look in this log.
You
most likely are doing something that keeps the thread from exiting.

Mongrel also deals with dead threads much better.  First the graceful
shutdown will wait 10 seconds for a request to finish before aborting it
during the shutdown process.  Second it will find processing threads
which
have taken longer than 60+timeout seconds and kill them.  Finally, you
can
put a value into your own Thread.current and when you use the thread.log
you
can figure out which controllers and actions are creating the bad
threads.

For example, lets say you see a thread leak.  Many times this is caused
by
trying to make a connection to a remote resource that isn't there, but
you're not sure.  What you do is put this into the suspected
controller's
action:

 Thread.current[:bad_controller_action] = true

Or some of other tag to differentiate it with the other threads.  Then
run
Mongrel with -B and if you see this in the KEYS list then you know that
this
is the controller.


MYSQL DROPPED CONNECTIONS? ANYONE?

Finally, there seems to be a bug in Rails where it is constantly
dropping
the connection to MySQL.  I've found this error on nearly everything and
it's worse when you run WEBrick.  It seems to get a little better when
you
set *ActionController::Base.allow_concurrency* in your
config/environments
the problem is lessened especially if you run Mongrel, which I don't
understand at all.

I'm still trying to determine the cause of this, but if you see this
problem
please report it to me with what system you are running and how often
you
see it.

**Remember, this is a Rails problem not a Mongrel problem since I see it
with WEBrick, FastCGI, SCGI, and on Win32, FreeBSD, OSX, and Linux.**


Zed A. Shaw
http://www.zedshaw.com/
http://mongrel.rubyforge.org/
Jonathan W. (Guest)
on 2006-04-06 23:10
(Received via mailing list)
>
> MYSQL DROPPED CONNECTIONS? ANYONE?

+ 1

I have many of "Mysql::Error: Lost connection to MySQL server during
query" exceptions in my logs...

Jonathan
This topic is locked and can not be replied to.