Rails - Apr 2006 - 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

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

>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 Bruun

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



-- 
Posted with http://DevLists.com.  Sign up and save your mailbox.

On Apr 4, 2006, at 10:08 AM, Wes Gamble 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! :-)

-- 
-- Tom Mornini

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 Mornini wrote:
> On Apr 4, 2006, at 10:08 AM, Wes Gamble 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! :-)
> 
> --
> -- Tom Mornini

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

Tom Mornini 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! :-)
 >

That would be me... the container junkie. :-D

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 Munat wrote:
> Tom Mornini 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! :-)
>  >
> 
> That would be me... the container junkie. :-D
> 
> 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

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

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.

On 4/5/06, Wes Gamble <weyus@att.net> wrote:
>
> 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
>
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060405/2638edf1/attachment.html

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.

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

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
http://www.freshports.org/net/ruby-spread
> - Clustering, failover, replication
Shared nothing is all about clustering, failover and replication
> - Remote deployment, management
Capistrano

-- 
-- Tom Mornini

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

On 4/5/06, Wes Gamble <weyus@att.net> wrote:
>
> 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.
>
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060405/a3b5a84f/attachment.html

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

b


Wes Gamble wrote:
> 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 Munat wrote:
> 
>>Tom Mornini 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! :-)
>> >
>>
>>That would be me... the container junkie. :-D
>>
>>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
> 
> 
>