Comments on: JRuby: The Future of Scalable Rails? http://www.codecommit.com/blog/java/jruby-the-future-of-scalable-rails (permanently in beta) Mon, 09 Jan 2012 20:21:24 -0800 http://wordpress.org/?v=2.9.2 hourly 1 By: Taylor Gautier http://www.codecommit.com/blog/java/jruby-the-future-of-scalable-rails/comment-page-1#comment-2136 Taylor Gautier Thu, 23 Aug 2007 08:44:18 +0000 http://www.danielspiewak.com/java/jruby-the-future-of-scalable-rails#comment-2136 James, That sounds really great. Was it hard to setup? Is there any way you can make any part of what you did available to the community? And of course I have to ask, did you try to cluster that Map with Terracotta? James,

That sounds really great. Was it hard to setup? Is there any way you can make any part of what you did available to the community? And of course I have to ask, did you try to cluster that Map with Terracotta?

]]> By: Daniel Spiewak http://www.codecommit.com/blog/java/jruby-the-future-of-scalable-rails/comment-page-1#comment-2047 Daniel Spiewak Tue, 24 Jul 2007 20:46:47 +0000 http://www.danielspiewak.com/java/jruby-the-future-of-scalable-rails#comment-2047 @James Very interesting. Did you try storing references to RObject within the session? So, rather than converting the Ruby objects into Java objects, just store the JRuby internal representation? Honestly, I don't know enough about JRuby internals to know if this avoids the problem or not. :-) @James

Very interesting. Did you try storing references to RObject within the session? So, rather than converting the Ruby objects into Java objects, just store the JRuby internal representation? Honestly, I don’t know enough about JRuby internals to know if this avoids the problem or not. :-)

]]> By: James Norton http://www.codecommit.com/blog/java/jruby-the-future-of-scalable-rails/comment-page-1#comment-2046 James Norton Tue, 24 Jul 2007 20:01:26 +0000 http://www.danielspiewak.com/java/jruby-the-future-of-scalable-rails#comment-2046 I realize I'm a little bit late to the party, but I thought I'd kick in my 2 cents from having used this approach (storing common resources in Java classes to be used across Rails instances). I have developed a JRuby application (deployed on Tomcat) that utilizes a large map of Java objects initialized from a database. This data structure is too large to keep a separate copy per instance - additionally it must be updated from the database when the underlying records change. Using a Java class (with Java thread synchronization) to hold this data in memory and manage updates outside of any particular Rails instance eliminates these two problems and scales well. Thanks for the tip. The only caveat I would add is that you can't store instances of Ruby objects in the Java class (except simple things like strings or numbers that get converted to Java objects). The references to the objects don't mean anything between sessions. I got burned on this at first, because I was developing using Webrick, which isn't multithreaded. When I would deploy to Tomcat things would break because of the invalid object references between rails instances. I realize I’m a little bit late to the party, but I thought I’d kick in my 2 cents from having used this approach (storing common resources in Java classes to be used across Rails instances). I have developed a JRuby application (deployed on Tomcat) that utilizes a large map of Java objects initialized from a database. This data structure is too large to keep a separate copy per instance – additionally it must be updated from the database when the underlying records change.

Using a Java class (with Java thread synchronization) to hold this data in memory and manage updates outside of any particular Rails instance eliminates these two problems and scales well. Thanks for the tip. The only caveat I would add is that you can’t store instances of Ruby objects in the Java class (except simple things like strings or numbers that get converted to Java objects). The references to the objects don’t mean anything between sessions. I got burned on this at first, because I was developing using Webrick, which isn’t multithreaded. When I would deploy to Tomcat things would break because of the invalid object references between rails instances.

]]> By: Daniel Spiewak http://www.codecommit.com/blog/java/jruby-the-future-of-scalable-rails/comment-page-1#comment-2048 Daniel Spiewak Sat, 16 Jun 2007 16:56:26 +0000 http://www.danielspiewak.com/java/jruby-the-future-of-scalable-rails#comment-2048 Hmm, I think that is what I mean when I said it, I just wasn't able to go into as much depth as you did. The other thing I was thinking was that using this model, you could scale the shared storage beyond the app servers. Huge sites (like the Diggs, Slashdots and Facebooks of the net) have massive farms of memcached servers separate from their actual app servers. So the model I had in mind was you separate out the resources devoted to the clustered SharedCache and make all of that work (and storage) take place on a whole separate set of servers (thanks to the magic of Terracotta). This way, you're free to cluster and load-balance and really do whatever you want with the app server without fear of interfering with your caching and storage. So pretty much, what you said. :-) Hmm, I think that is what I mean when I said it, I just wasn’t able to go into as much depth as you did.

The other thing I was thinking was that using this model, you could scale the shared storage beyond the app servers. Huge sites (like the Diggs, Slashdots and Facebooks of the net) have massive farms of memcached servers separate from their actual app servers. So the model I had in mind was you separate out the resources devoted to the clustered SharedCache and make all of that work (and storage) take place on a whole separate set of servers (thanks to the magic of Terracotta). This way, you’re free to cluster and load-balance and really do whatever you want with the app server without fear of interfering with your caching and storage.

So pretty much, what you said. :-)

]]> By: Taylor Gautier http://www.codecommit.com/blog/java/jruby-the-future-of-scalable-rails/comment-page-1#comment-2057 Taylor Gautier Sat, 16 Jun 2007 02:09:25 +0000 http://www.danielspiewak.com/java/jruby-the-future-of-scalable-rails#comment-2057 I'm confused again - I could swear that's what you meant when you said: "As the application scaled and the shared data requirements increased, the SharedCache class (as we’ll christen it) could be modified to cluster, using Terracotta" Basically, to be clear, what I see is that per app-server you have a single WAR. Via the JRuby-extras project you can run some n Rails instances from that WAR (as depicted in your diagram). But a single app-server can only handle so many Rails instances, so then you need to deploy another app-server with another application WAR that can handle another n Rails instances. In the single app-server case the SharedCache datastructure lived in the process/heap space of the JVM hosting the app-server and (and therefore) the Rails instances, thus data consistency wasn't a problem, but now across app-servers it is. This is where Terracotta kicks in. Right? (And specifically, the class doesn't have to be modified to be clustered by Terracotta, but that's beside the point). I jumped on the thread because I agree it is very useful and would be happy to help out getting a prototype done. I’m confused again – I could swear that’s what you meant when you said:

“As the application scaled and the shared data requirements increased, the SharedCache class (as we’ll christen it) could be modified to cluster, using Terracotta”

Basically, to be clear, what I see is that per app-server you have a single WAR. Via the JRuby-extras project you can run some n Rails instances from that WAR (as depicted in your diagram). But a single app-server can only handle so many Rails instances, so then you need to deploy another app-server with another application WAR that can handle another n Rails instances. In the single app-server case the SharedCache datastructure lived in the process/heap space of the JVM hosting the app-server and (and therefore) the Rails instances, thus data consistency wasn’t a problem, but now across app-servers it is.

This is where Terracotta kicks in. Right? (And specifically, the class doesn’t have to be modified to be clustered by Terracotta, but that’s beside the point). I jumped on the thread because I agree it is very useful and would be happy to help out getting a prototype done.

]]> By: Daniel Spiewak http://www.codecommit.com/blog/java/jruby-the-future-of-scalable-rails/comment-page-1#comment-2056 Daniel Spiewak Sat, 16 Jun 2007 01:24:03 +0000 http://www.danielspiewak.com/java/jruby-the-future-of-scalable-rails#comment-2056 @Parallel shared nothing: Yeah, pretty much. I just wasn't able to put it so eloquently. :-) Hmm, I hadn't actually thought too much about the possibilities of separate JRuby instances using the same SharedCache, but I suppose that would really be a useful thing to have. Easier too than clustering the JRuby instance since you're actually doing it in raw Java. Seems there's a lot more to this concept than I initially considered. :-) Maybe you're right and this would be worth a full-blown project. When I was writing the article, I had in mind just a singleton class with thread safety built in. The Terracotta thing was mainly because it seemed to be a really neat way to scale the shared data-handler further. But you're right that this would be far more useful as a more capable solution that was designed to cluster. @Parallel shared nothing: Yeah, pretty much. I just wasn’t able to put it so eloquently. :-)

Hmm, I hadn’t actually thought too much about the possibilities of separate JRuby instances using the same SharedCache, but I suppose that would really be a useful thing to have. Easier too than clustering the JRuby instance since you’re actually doing it in raw Java. Seems there’s a lot more to this concept than I initially considered. :-)

Maybe you’re right and this would be worth a full-blown project. When I was writing the article, I had in mind just a singleton class with thread safety built in. The Terracotta thing was mainly because it seemed to be a really neat way to scale the shared data-handler further. But you’re right that this would be far more useful as a more capable solution that was designed to cluster.

]]> By: Taylor Gautier http://www.codecommit.com/blog/java/jruby-the-future-of-scalable-rails/comment-page-1#comment-2054 Taylor Gautier Sat, 16 Jun 2007 00:45:22 +0000 http://www.danielspiewak.com/java/jruby-the-future-of-scalable-rails#comment-2054 I wasn't arguing that you don't need more Rails instances, that's exactly what this solution allows - to run each JRuby instance in it's own interpreter space, roughly equivalent to threads / jvm. When you run out of processing power for this model, you need to add more nodes, and it's at this point that the clustered version of the SharedCache via Terracotta kicks in (until that point, concurrent access to the SharedCache is mediated by Java's built in concurrency controls). Actually clustering the data / using clustered concepts inside of the JRuby instances is really interesting, but as far as I understand it, it's not the model that Rails is built on so it's not necessary to build scale-out for a Rails app. That's what you were saying when you stated that Rails is a parallel shared-nothing model, right? I wasn’t arguing that you don’t need more Rails instances, that’s exactly what this solution allows – to run each JRuby instance in it’s own interpreter space, roughly equivalent to threads / jvm. When you run out of processing power for this model, you need to add more nodes, and it’s at this point that the clustered version of the SharedCache via Terracotta kicks in (until that point, concurrent access to the SharedCache is mediated by Java’s built in concurrency controls).

Actually clustering the data / using clustered concepts inside of the JRuby instances is really interesting, but as far as I understand it, it’s not the model that Rails is built on so it’s not necessary to build scale-out for a Rails app.

That’s what you were saying when you stated that Rails is a parallel shared-nothing model, right?

]]> By: Daniel Spiewak http://www.codecommit.com/blog/java/jruby-the-future-of-scalable-rails/comment-page-1#comment-2049 Daniel Spiewak Fri, 15 Jun 2007 19:16:07 +0000 http://www.danielspiewak.com/java/jruby-the-future-of-scalable-rails#comment-2049 @Taylor Yeah, this probably would allow you to avoid clustering JRuby for a little while, but this only takes care of memory/storage requirements. If you're starting to run out of processor space for the extra Rails instances, you still probably need to cluster the JRuby instance. @Taylor
Yeah, this probably would allow you to avoid clustering JRuby for a little while, but this only takes care of memory/storage requirements. If you’re starting to run out of processor space for the extra Rails instances, you still probably need to cluster the JRuby instance.

]]> By: Taylor Gautier http://www.codecommit.com/blog/java/jruby-the-future-of-scalable-rails/comment-page-1#comment-2050 Taylor Gautier Fri, 15 Jun 2007 18:38:00 +0000 http://www.danielspiewak.com/java/jruby-the-future-of-scalable-rails#comment-2050 Now this is incredibly interesting, because in fact if I am reading the implementation correctly, it's not required to cluster JRuby at all, but just this class/implemenation providing virtual storage. In other words, this implementation can go forward today, without having to worry about the complexities of clustering JRuby (which while cool to the nth degree, is still in the experimental phase, no offense to Jonas). Could we start this project as a labs at http://www.terracotta.org/confluence/display/labs/Home? If there is any interest, please email me at tgautier - at - terracotta.org. Now this is incredibly interesting, because in fact if I am reading the implementation correctly, it’s not required to cluster JRuby at all, but just this class/implemenation providing virtual storage.

In other words, this implementation can go forward today, without having to worry about the complexities of clustering JRuby (which while cool to the nth degree, is still in the experimental phase, no offense to Jonas).

Could we start this project as a labs at http://www.terracotta.org/confluence/display/labs/Home?

If there is any interest, please email me at tgautier – at – terracotta.org.

]]> By: Daniel Spiewak http://www.codecommit.com/blog/java/jruby-the-future-of-scalable-rails/comment-page-1#comment-2051 Daniel Spiewak Fri, 15 Jun 2007 15:50:36 +0000 http://www.danielspiewak.com/java/jruby-the-future-of-scalable-rails#comment-2051 @Nick Oh now seriously, that's about as cool as it gets. I didn't know about that or I would have included it in the article. Way, way, way cool! :-) @Nick
Oh now seriously, that’s about as cool as it gets. I didn’t know about that or I would have included it in the article. Way, way, way cool! :-)

]]>