Ruby server infrastructure evolution -> app. servers?

All,

Just musing about this whole FastCGI thing (that I hadn’t even thought
of since 1999 when looking at OpenMarket for a customer and even then it
was “old”), and wondering when we might see projects/products that
attempt to provide Ruby application services in a J2EE-like container.

I see the Cerise project - any interesting information on that?

I’m assuming that at some point, people will want the flexibility to run
their Rails code on a separate machine from the Web server, etc. On the
other hand, the Rails package seems to provide a lot of nice “container”
features, such as caching, DB setup management, etc.

Thoughts - do we need a Rails container? If so, thoughts on when that
might come to pass?

Wes

I’m assuming that at some point, people will want the flexibility to run
their Rails code on a separate machine from the Web server, etc. On the
other hand, the Rails package seems to provide a lot of nice “container”
features, such as caching, DB setup management, etc.

using fcgi its possible to run your webserver and appserver on different
hosts…

People are generally fascinated by the whole container concept…but
why??

the container usually mimicks the services that the OS/other tools are
supplying

Mikkel B.

www.strongside.dk - Football Portal(DK)
ting.minline.dk - Buy Old Stuff!(DK)

On Apr 4, 2006, at 10:08 AM, Wes G. wrote:

I’m assuming that at some point, people will want the flexibility
to run
their Rails code on a separate machine from the Web server, etc.

FastCGI allows this now.

Thoughts - do we need a Rails container? If so, thoughts on when that
might come to pass?

I can’t think of his name, but I know at least one list reader is going
to give you a big “Hallelujah!” on that one! :slight_smile:


– Tom M.

Tom M. wrote:

I can’t think of his name, but I know at least one list reader is
going
to give you a big “Hallelujah!” on that one! :slight_smile:

That would be me… the container junkie. :smiley:

Actually, I started out arguing for a container because, well, that’s
the way we do it in
the java world. But in the course of that, I came to understand the
benefits of the “share
nothing” approach… I can see why many people like mandating
statelessness upon
themselves across the board.

However, I also like having an application context if I need it (I know,
I know… I can
make whatever I want available by DRb… but it’s not the same.) And
ultimately it would
be nice to have the choice. That would be another trump card for Ruby
actually, cuz in the
Java world it’s pretty much servlets or nothing.

Wes, thanks for the tip on Cerise… will keep an eye on that. I wonder
how hard it would
be to get it to run a rails app?

b

Ben,

You’ve touched on a couple of interesting topics.

“Share nothing” struck me as a “we don’t have a session replication
story” excuse. Which is understandable since Rails is all of 18 mos.
old. The downside of “share nothing” is more round trips to the
persistence store.

Also, I read in AWDWR about the session backing store stuff. I just
accept that sessions will be lost if the container crashes in the J2EE
world (unless I’m doing something like session replication, of course).
The heavy admonition against using an in-memory store for session
backing struck me as odd as a result.

I keep thinking how cool it will be when rails runs on jruby - sure for
access to java objects in the JVM. But then I was trying to think if
there would be any benefit to running rails on JRuby in a J2EE
container, but I couldn’t come up with anything off the top of my head.
Any thoughts? Where would a J2EE container fill in the gaps in the
Rails world? Would having access to JNDI repositories be exciting?
What about JDBC/ActiveRecord stuff? Any thoughts?

Wes

Ben M. wrote:

Tom M. wrote:

I can’t think of his name, but I know at least one list reader is
going
to give you a big “Hallelujah!” on that one! :slight_smile:

That would be me… the container junkie. :smiley:

Actually, I started out arguing for a container because, well, that’s
the way we do it in
the java world. But in the course of that, I came to understand the
benefits of the “share
nothing” approach… I can see why many people like mandating
statelessness upon
themselves across the board.

However, I also like having an application context if I need it (I know,
I know… I can
make whatever I want available by DRb… but it’s not the same.) And
ultimately it would
be nice to have the choice. That would be another trump card for Ruby
actually, cuz in the
Java world it’s pretty much servlets or nothing.

Wes, thanks for the tip on Cerise… will keep an eye on that. I wonder
how hard it would
be to get it to run a rails app?

b

Tom,

Thanks for this.

Can you point me in the direction of the info. about how FastCGI
supports remote hosting of Ruby separate from the Apache process?

I do see that the fcgi is run as a separate proc. so it makes sense.
But where is the socket management that would need, etc.?

Wes

Tom M. wrote:

On Apr 4, 2006, at 10:08 AM, Wes G. wrote:

I’m assuming that at some point, people will want the flexibility
to run
their Rails code on a separate machine from the Web server, etc.

FastCGI allows this now.

Thoughts - do we need a Rails container? If so, thoughts on when that
might come to pass?

I can’t think of his name, but I know at least one list reader is going
to give you a big “Hallelujah!” on that one! :slight_smile:


– Tom M.

My JRuby alert went off…ding ding ding!!!

I think JRuby on Rails in a J2EE container (or other app framework like
Spring) could have huge potential. Some of these you’ve mentioned, but:

  • ActiveRecord over JDBC
  • EJBs as DRb services
  • EJBs implemented in Ruby
  • Spring services implemented in Ruby
  • JMS as…well what does Ruby have for messaging today?
  • Clustering, failover, replication
  • Remote deployment, management
  • Existing JSPs as Rails UI
  • ERB as Java/Rails UI
  • Poor sap J2EE architects like me might have something interesting to
    work
    on in Java-only shops

Despite many statements to the contrary, although developing for J2EE is
an
exercise in pain, J2EE servers have extremely robust features not found
in
any other deployment target today (without a lot of fiddling around). If
you
want to keep things in the small, deploying JRuby on Rails inside a
Spring
container gives you much of the same agility as Ruby on Rails.

For these reasons, and many more, we on the JRuby team thing Rails would
be
a killer app for JRuby just like it is for Ruby. We’re working hard to
make
it a reality.

Messaging - that’s compelling.

Session replication would require that the sessions are managed by the
J2EE side of things or there is some sort of session mapping scheme.
That’s an interesting ide-er…

Thanks Charles.

If I get some time, I’d love to help test JRuby.

wes

Charles O Nutter wrote:

My JRuby alert went off…ding ding ding!!!

I think JRuby on Rails in a J2EE container (or other app framework like
Spring) could have huge potential. Some of these you’ve mentioned, but:

  • ActiveRecord over JDBC
  • EJBs as DRb services
  • EJBs implemented in Ruby
  • Spring services implemented in Ruby
  • JMS as…well what does Ruby have for messaging today?
  • Clustering, failover, replication
  • Remote deployment, management
  • Existing JSPs as Rails UI
  • ERB as Java/Rails UI
  • Poor sap J2EE architects like me might have something interesting to
    work
    on in Java-only shops

Despite many statements to the contrary, although developing for J2EE is
an
exercise in pain, J2EE servers have extremely robust features not found
in
any other deployment target today (without a lot of fiddling around). If
you
want to keep things in the small, deploying JRuby on Rails inside a
Spring
container gives you much of the same agility as Ruby on Rails.

For these reasons, and many more, we on the JRuby team thing Rails would
be
a killer app for JRuby just like it is for Ruby. We’re working hard to
make
it a reality.

Well feel free to pop on over the jruby.sf.net and subscribe to the
mailing
lists. We’ve almost got Rails running, and we’re presenting at
JavaOne.
We’re pretty motivated to at least get a basic request to work before
the
conference, May 16-19.

I won’t make any promises about speed yet; JRuby has always been slow to
run
large apps, and although I’ve been leading a redesign of the core
interpreter, we’re still focusing primarily on making it “correct”
before we
make it “fast”. However, I hope to change that in the next six months by
introducing compilation and more advanced VM features to kick up the
speed.

I’ve been updating my blog, headius.blogspot.com, about once a week with
JRuby updates, so that’s another way to keep tabs. Thanks for your
interest
:slight_smile:

On Apr 5, 2006, at 12:14 AM, Charles O Nutter wrote:

  • JMS as…well what does Ruby have for messaging today?

http://www.spread.org

  • Clustering, failover, replication

Shared nothing is all about clustering, failover and replication

  • Remote deployment, management

Capistrano


– Tom M.

Nah, I don’t think it’s as much “we haven’t gotten around to that” as
much as the fact
that Ruby/Rails come from different background than Java… mostly
informed by the “*nix
as a platform” concept. Once upon a time I thought the LAMP concept was
weird, but then I
started to understand that all the little tools of the OS are the
counterparts of all the
little libraries of Java.

My main interest in a container is less connection pools and enterprise
stuff and more
things like ease of access to static data, non-annihilation of your
application state on
each request, having multiple threads able to share some stuff. But all
of that is
possible in rails. I sincerely doubt there is anything you can do in
Java that you can’t
figure out some way to do in Ruby.

One more irony that I keep thinking about: the whole “share nothing”
mantra of rails is
actually somewhat like pre-optimization. I have only worked on apps that
are used by a
limited number of employees at a given organization. I have never needed
to put an app on
a cluster. And actually, most of these are java apps running in a
servlet container (often
with several other apps running in there too) talking to a database on a
separate machine.
But they’re small enough to really run on the same machine with the db
– with several
other apps sharing the hardware – and not have any trouble. Rails seems
to have gone
straight for the gusto and settled on “clusterability” as the default.

Oh, and I agree that there is a very pervasive “just stick it in the db”
attitude in the
rails world. Maybe we java people have just been doing our own
pre-optimization all these
years, but I have done back-flips to figure out how to replace two
queries with one. But
now that I’m rolling on rails, I’m gonna stick every last thing I can in
the db and get it
over and over and over again. :slight_smile:

b