How to put a Ruby website online without rails

ruby-talk
21

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.

···

On Feb 15, 2008, at 2:34 PM, Michael Granger wrote:

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).

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.

22

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

···

--
Posted via http://www.ruby-forum.com/.

23

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.

···

On Feb 15, 2008, at 3:11 PM, s.ross wrote:

--
Michael Granger <ged@FaerieMUD.org>
Rubymage, Architect, Believer
The FaerieMUD Consortium <http://www.FaerieMUD.org/&gt;

24

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

···

On Sat, Feb 16, 2008, Softmind Technology wrote:

25

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. :stuck_out_tongue:

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.

···

On Feb 15, 2008, at 8:19 PM, Softmind Technology wrote:

--
Michael Granger <ged@FaerieMUD.org>
Rubymage, Architect, Believer
The FaerieMUD Consortium <http://www.FaerieMUD.org/&gt;

26

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

···

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.

27

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.

···

On Feb 15, 2008, at 11:42 PM, Michael Granger wrote:

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.

28

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.

···

--
Posted via http://www.ruby-forum.com/\.

29

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. :slight_smile:

···

On Feb 16, 2008, at 11:32 AM, s.ross wrote:

--
Michael Granger <ged@FaerieMUD.org>
Rubymage, Architect, Believer
The FaerieMUD Consortium <http://www.FaerieMUD.org/&gt;