That’s funny Rick, cuz I feel dense at least once a day every day.
As in my response on this topic to Kent, I have to admit that there is a
possibility that
my Java experience colors my view of this and I’m attaching more
significance to a servlet
container than necessary. But I really don’t think so.
The very first thing I learned about Java for the web and servlets is
that this concept
was a giant leap forward for web development. Rather than having to
create a process,
execute the request, and the kill and clean up the process for every
request, servlets
gave the web programmer a single, multi-threaded, long-running process
into which she
could hook her applications. It wasn’t too long before they added in
other useful features
like connection pools and the other pieces of the j2ee stack.
But really, the best thing about the container concept is that you have
a single global
memory space for your app. The multiple copies created by the
multi-threading is fairly
transparent to you (you just have to be careful of a few things).
Now, FastCGI addresses the process life-cycle problem, but it does not
give one an
application environment. Maybe the rails folks coming from the
sysadmin/PHP/perl world are
comfortable enough with the OS being their environment. Maybe that’s
just as valid an
application environment. I don’t really see how it can be as portable as
a container
process. I can download tomcat, unzip it, drop my .war into the webapp
folder and start
the server and it just works… on all major platforms… no muss no
fuss.
I’ve also gotten the (possibly incorrect) impression that the current
rails environment
doesn’t allow for static application state to be maintained in memory
indefinitely. This
came up on a thread about the inability to store threads or procs in
sessions. I pointed
out that one could keep the non-serializable stuff in an in-memory hash
and store a
(serializable) string key for that non-serializble object in the
session.
But then I realized that I think – and I still haven’t gotten a
straight answer to this
– one can’t really do that with the FastCGI approach: Having a bunch of
processes running
at the end of a pipe so that you don’t suffer the process life-cycle
pain is all well and
good. But each of those processes is separate… you can’t have a global
in-memory storage
of stuff like my thread map or configuration or cached lookup values or
what have you. Or
can you?
I imagine there’s some way of starting another ruby process that has
this common state and
each fcgi process connects to that process… er, in fact I think that
was Ezra’s
solution: stick your stuff you need in a drb process and have your app
get if from there
when you need it.
I still maintain that it’s not the same. I still think that a lot of
folks in the
Java/.Net world ain’t gonna buy that. I’m surprised that more Java folks
aren’t coming to
my aid here… maybe I’m just a crazy guy ranting to the magazine stand.
Or, I’d be happy
enough if a Java convert told me why they think this isn’t an issue.
It’ll be interesting to see where this is in six months; whether mongrel
has made all us
insecure container-heads happy… whether I’ll just learn the tools that
exist and shut
up… whether this issue will grow as an impediment to rails adoption.
In the meantime, I’ll try to shut up and learn the tools.
b
PS: I think it interesting to note the volume of “help help, my fastcgi
setup isn’t
working” posts on this list. On all the Java lists I’ve ever been on,
there’s very little
“why doesn’t my tomcat work”? That’s cuz it just does.