On Feb 16, 2008, at 11:32 AM, s.ross wrote:
I don’t think that the issue is of mod_ruby, but rather of people’s
expectations of mod_ruby. I think they expect it to behave as
mod_perl and mod_php do. But Ruby is a very different language with
very different issues.
I’m not sure what different behavior you’re referring to. mod_ruby
behaves nearly identically at least to mod_perl (I don’t have any
experience using either PHP or mod_php) with respect to namespace
collision and re-entrancy. I’ve written a lot of code for both
environments, and they both require the same discipline when it comes
to memory management and scoping of variables.
One reference you might find useful in understanding the perception
shared among many Ruby developers is this:
http://wiki.rubyonrails.org/rails/pages/mod_ruby
I don’t deny that people’s perception of mod_ruby is influenced by the
difficulty of running Rails under it, but my point is that Rails isn’t
the only web application framework, and is written with the
assumption that it’s the only code in the ObjectSpace. Just because it
won’t run Rails comfortably doesn’t disqualify mod_ruby from being a
viable way to deploy applications for the web.
Before you say, Ruby is not Rails (or vice versa), I would add
quickly that people who are experiencing mod_ruby problems are very
often Rails developers, and almost all documentation on deployment
encourages a multi-process rather than multi-thread deployment
model. Can’t say I blame them.
Sure, but if you’ll examine the subject of this thread, I hope you may
excuse my making the assumption that Michal’s post was talking about
web application environments other than Rails.
My guess is that if you are a good programmer, versed in the subtle
bugs that can creep into re-entrant programs or if you are running
exactly one Web application per Apache, then you’ll be ok.
Sure, but I don’t think I’m an especially good programmer and I’ve
managed to write code that runs under that environment without the
problems that seem to be the common complaint. You don’t need to be
any more mindful of the kind of reentrancy you’re talking about with
mod_ruby (running under the pre-fork MPM) than you do with Rails or
any other single-threaded application.
I don’t know because although I would dearly love to, I have not
successfully deployed anything on mod_ruby, […]
Just out of curiosity, how many non-Rails applications have you tried
to deploy under mod_ruby?
[…] and given the fact that merb, thin, Rails, and most other Ruby
Web frameworks deploy most successfully on top of mongrel or Rack,
it’s not likely I’ll swim upstream on this one.
If you’ve chosen a framework already, and it doesn’t run under
mod_ruby, I’d consider that a perfectly valid reason not to choose it
or to recommend against it. If that had been the original question,
I’d have stayed happily off in my corner, using a framework written
exactly to run under mod_ruby, and which has been quietly doing the
things which people have been saying can’t be done.