How to put a Ruby website online without rails

[s.ross]

Please, if you must post advice against using a particular piece of
software, please provide concrete evidence of its unsuitability.
Conjecture is mildly interesting in some situations, but when you
impugn someone else's hard work you should at least have the
courtesy to give examples, hard facts, or at the very least stick to
points which you don't have to qualify with "probably".

I'd be happy to provide further details if anyone's interested. I'm
just getting tired of the FUD and hastily-posted conjecture about
what constitutes appropriate technology for building web applications.

Yes, I am interested. There is a widely-held perception based on
information from well-respected Rubyists and Rails people that
mod_ruby has problems related to managing re-entrant code. This might
translate to: "Most users don't have the background to set mutexes so
they will eventually stomp on data that's not thread-save" but it
might also translate to: "This ain't mod_php, guys. You can do bad
things and never know until it's too late."

So, yes, a clarification would be extremely useful.

 

[Softmind Technology]

Hi,

Sorry for jumping in.

If Mod_ruby was so easy to write.. than why its not written so far...?

Why did Engine Yard hire few skilled Programmers to work full time on
Mod_Ruby.?

Why does maximum Ruby developers are demanding and cursing the lack of
mod_ruby and the lack of easy deployment of Ruby on Rails die to
improper mod_ruby.

I think... majority cant be wrong. There's something missing in the
proper mod_ruby implementation.

may be Engine Yard can focus more on this...

Cheers

 

[Ben Bleything]

If Mod_ruby was so easy to write.. than why its not written so far...?

What? It's written fine. What makes you say it's not?

Why did Engine Yard hire few skilled Programmers to work full time on
Mod_Ruby.?

Because they don't use mod_ruby and have no need to employ people to
work on it?

Why does maximum Ruby developers are demanding and cursing the lack of
mod_ruby and the lack of easy deployment of Ruby on Rails die to
improper mod_ruby.

*rails* developers don't like mod_ruby. Rails is only one way to write
a webapp in Ruby. mod_ruby doesn't work that well with Rails, but it
works just fine for me.

I think... majority cant be wrong. There's something missing in the
proper mod_ruby implementation.

Oh really? What's missing?

may be Engine Yard can focus more on this...

Why?

Ben

 

[Michael Granger]

You probably can't even create
multiple threads running ruby safely (as opposed to creating
multiple
ruby threads inside one native thread of execution as is done in the
interpreter).

[...]
I'd be happy to provide further details if anyone's interested. I'm
just getting tired of the FUD and hastily-posted conjecture about
what constitutes appropriate technology for building web
applications.

Yes, I am interested. There is a widely-held perception based on
information from well-respected Rubyists and Rails people that
mod_ruby has problems related to managing re-entrant code.

mod_ruby, at its core, is two things: a Ruby interpreter embedded into
Apache that can be called into during the various stages of a request,
and a collection of classes that express the Apache API in Ruby. The
interpreter that is embedded is neither more nor less re-entrant than
that run from the command line, which is to say that it isn't for any
interpreter up to and including 1.8.6.

I run mod_ruby apps under the Apache "pre-fork" MPM, so perhaps there
are issues with the interpreter's re-entrancy when running under the
"worker" or "event" MPMs -- but then again the person I was replying
to didn't mention MPMs at all, he just stated that mod_ruby was to be
avoided altogether.

Does the common complaint about mod_ruby really boil down to Ruby's
lack of re-entrancy? Or maybe this is just a re-phrasing of the
"shared hosting problem"? I mentioned in the previous post that
mod_ruby is probably not suitable for running untrusted code or in
shared environments without additional partitioning, but I still don't
think that describes the majority of situations, and it certainly
doesn't warrant dismissal of the whole package outright.

If any of the aforementioned "well-respected Rubyists and Rails
people" have additional light to shed on this, I'd love to know where
this "widely-held perception" is coming from. I've been using mod_ruby
since late 2002, and I haven't happened upon anything that would
indicate that it deserves the reputation it seems to have gained.

This might translate to: "Most users don't have the background to
set mutexes so they will eventually stomp on data that's not thread-
save" but it might also translate to: "This ain't mod_php, guys. You
can do bad things and never know until it's too late."

I'm still not convinced that there's lots of threaded web applications
out there that require mutexes and the like, but sure: with great
power comes great responsibility. You have to program with more
discipline when you're writing applications that run for long periods
of time and share an ObjectSpace with other code, but that's what
Module and Kernel#load('myfile', true) are for (among other things of
course). Programmers who splat their code all over the Ruby
ObjectSpace, can't resist the urge to reopen every core class under
the sun to inject their own pseudo-clever trinket methods, and can't
be bothered to namespace their class libraries should probably stick
to environments where their crap runs in a safe little box that can be
kill -9ed when it inevitably hangs or gets too bloated.

So, yes, a clarification would be extremely useful.

I actually meant if anyone wants more specific details about how to
write applications under mod_ruby, then I'd be happy to furnish them,
but I realize I didn't state that quite clearly enough. I hope this
sufficed for a clarification anyway.

 

[Michael Granger]

Sorry for jumping in.

If Mod_ruby was so easy to write.. than why its not written so far...?

It's not? Shugo-san will be very surprised, I think, to learn that
he's not actually written anything. And crap, I wrote a whole
framework around software that doesn't exist?! Damn, I guess I should
probably tell the company I work for that their intranet is a figment
of my imagination, too.

Why did Engine Yard hire few skilled Programmers to work full time on
Mod_Ruby.?

They didn't -- they hired skilled programmers (hi Ryan and Eric!) to
work full time on Rubinius, and have talked about writing a
"mod_rubinius", which I would assume was an Apache module that
embedded a Rubinius interpreter.

Why does maximum Ruby developers are demanding and cursing the lack of
mod_ruby and the lack of easy deployment of Ruby on Rails die to
improper mod_ruby.
Ignorance?

I think... majority cant be wrong.

The majority can certainly be wrong. History is rife with examples.

There's something missing in the proper mod_ruby implementation.

Which is...?

may be Engine Yard can focus more on this...

They already have their hands full on their own stuff, so I doubt it.

 

[chris.mccauley]

Hi,

Just my own opinion but I think that anyone who is "demanding and
cursing" should take a look at other simple ways to deploy Ruby &
Rails applications. For me, nginx and mongrel cluster provide a simple
and scalable way to deploy applications. I don't think mod_ruby adds
much for me.

Chris

 

[s.ross]

Does the common complaint about mod_ruby really boil down to Ruby's
lack of re-entrancy? Or maybe this is just a re-phrasing of the
"shared hosting problem"? I mentioned in the previous post that
mod_ruby is probably not suitable for running untrusted code or in
shared environments without additional partitioning, but I still
don't think that describes the majority of situations, and it
certainly doesn't warrant dismissal of the whole package outright.

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. So, as you say, "with great power..."

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

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.

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. I don't
know because although I would dearly love to, I have not successfully
deployed anything on 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. I'm just clarifying why the *perception* seems to be out there.

 

[Marc Heiler]

it's not likely I'll swim upstream on this one.

I totally understand your point. I also have not had much luck on
mod_ruby and eventually sticked to use .cgi pages. But it works nicely
and kuwata-lab has this little add-on for reading error messages right
in the .cgi page, instead of looking at the apache error log

I also dont even embed any code into .html pages, everything is
generated via ruby scripts here. Still need a restful event system, at
best something that is very small and works without webrick too.

One disadvantage I personally see with the rails way is that it is very
rails specific. I dont want to be forced to think that way at all, even
if its
superior. And this is also one reason why I hope for more smart people
like
http://www.kuwata-lab.com/ so that there is more diversification.

The www is very important in my opinion (and I preach on this topic too
often anyway), and its also equally important to acknowledge this and
improve on web-related things (mod_ruby) and help grow many more
web-related projects. I think this was one reason of rails success,
because people needed something for the web.

I am also glad the situation has improved a lot in the last ~2 years on
that, there are really many new projects and i hope they overcome the
problems of other projects, like lack of docu or similar (like nitro, it
had a big problem regarding documentation, and if you look at ogre3d i
believe providing docu is always a big requirement, not only for
understanding, BUT also for _learning_/_teaching_ other people.

 

[Michael Granger]

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.