Hi Zed

On Sun, 2006-04-23 at 02:53 +0900, Zed Shaw wrote:
> With Mongrel you've got the situation that a single Mongrel server could
> potentially be handling many requests at once, so killing off a dead one
> could really make things bad.  But, in a shared hosting environment this
> would perfect for catching the poorly coded servers that eat up resources.

Yes, the library is better suited for a multi-process model, like the
pre-forking MPM in apache2, because we can just kill the process that is
eating the resources without killing the whole server.

I'm actually not very familiar with Mongrel (just used it for a simple
Camping app), although I'm planning to when time permits. I'm guessing
that to make it work with Mongrel, one would need a wrapper script to
launch the server, so that it could be relaunched after it's killed.
Does that make sense?

> I kind of like this solution though since it is more difficult for the
> person to cheat.  They can't really turn it off by injecting Ruby code since
> they still have to talk to the watchcat.  I'm curious if they could cheat
> other ways such as transferring the socket to another process which always
> works.

In our environment, the user has no control of the watchcat (it is
created by mod_watchcat), so to pass the socket descriptor to another
process the user would first have to guess what the descriptor is. It's
not impossible to do it, but then it would be easy for us to identify a
user doing that.

Regards,
Andre