MagLev was a show from the last RailsConf (2008). Presentation and demos of the product are really impressive.
Recently, Brian Takita asked in the JRuby mailing list:
JRuby + TerraCotta == Maglev?
What an idea! In the last few days I’ve tried to make something useful and I’m happy to have something to show.
Screencast: Reproducing Avi Bryant's Demo with JRuby + Nailgun and JRuby + Terracotta. (5 min)
The first demo runs with Nailgun. The basic idea is to share a single Java VM across all clients, so they can share some objects. The second is much more complete, as its clients have their own Java VM. There are many true interpreters running, and they are sharing objects through Terracotta. Terracotta is responsible for sharing memory in Java VM clusters and, despite of its slow startup, has much more to offer. The shared objects (hats and rabbits) could be automatically persisted by Terracotta, as MagLev also does.
I’ve patched JRuby and configured Terracotta to make demos run. I’ll upload the patches and configuration somewhere, ASAP.
Working on JRuby to make it run multiple runtimes (VMs) at the same time is being really fun!
Fabio Kung 
Awesome demo, very clever solution to the multi-vm problem, this is a very approachable solution, specially for server-side stuff where startup time is not that relevant.
Very interesting. Honestly this is what really gets me going when I hear Maglev: sharing automatically replicated/persisted objects through workers. I guess I’ll have to read up more on Terracota.
Pretty interesting demo. As a Terracotta developer I am happy to see ppl poking our product in interesting ways like this.
One of my collegue had once played around clustering Jruby with Terracotta sometime back.
Dunno if you had checked it out or not.
http://jonasboner.com/2007/02/05/clustering-jruby-with-open-terracotta/
cheers,
Saravanan
Thanks for the link Saravanan. Yes, I’ve seen it, but I took a different approach.
The main difference is that in my version of the Terracotta integration, all global variables are automatically shared across JVM cluster nodes. It is “transparent”, as it doesn’t require any explicit control in the Ruby code.
Muito bom!
I love it! Transparent JRuby clustering. Good idea there.
–Ari
Very impressive! Just as impressive as the original MagLev demo that I was lucky enough to see at RailsConf.
Very nice.
1) Are the required JRuby changes likely to make it into a released JRuby?
2) Was the Terracotta ‘side-of-things’ written as a Terracotta Integration Module (TIM)?
@Mark
1) Unfortunately not in the next (1.1.5). There are things that must be tuned yet. I’ve already discussed a bit with Charles Nutter. The main points are: a) global object identity, b) shared metaclasses. But it is already usable.
2) Not yet. That is my next step; or perhaps I will open the source in github first.
That’s really interesting – however I doubt that your approach with making all global variables accessible from all instances will make big community around it. I think it’s better to specify which variables you need to share, and rest (default) shouldn’t be shared.
Hi Fabio! I’m a Java/JRuby dev, it’s been over a year since I first read about your JMagLev concept, and I was wondering if you had made any updates to your project recently?
I’m interested in using it with the latest version of JRuby (1.5.3), and I have two questions:
Is there a version available (or method for achieving the same) that does not require a patch to the JRuby source (since it is often changing)? That is, is there a way to simply programmatically specify particular ruby classes or – even better – individual ruby variables in the JVM for sharing across JVMs?
Is there a TIM yet?
Thanks in advance for your time, and well done with this project!
Hi Nels,
Thanks for your comments! Unfortunately I haven’t had any time yet to play with this JRuby/Terracotta integration. Then, answering your questions, there isn’t a new version. 😦
Regarding the TIM, I haven’t heard anything from the Terracotta guys. Probably there isn’t one yet.
I’m curious about what you are going to do with this stuff. Can you tell something about it?
Well, I have two ideas, both just experiments. For one, I’d like to try to play around with a no-sql web-application using Apache Tomcat and JRuby with a small Terracotta cluster for persistence. I work for a company that makes use of service-oriented web-applications, for just about everything. One of the bottlenecks in the collection of systems has always been these domain-specific web-services being chained together. It’d be nice to have a one-stop shop for all the data necessary for all applications. But scalability for such solutions is always an issue. If a Big Memory Terracotta cluster could be leveraged by an unlimited number of load-balanced VMs, then we might have a shot at such a solution. The only problem would then be transaction management against the database. But if the database could be eliminated altogether, then maybe it could work.
The other is for a personal project, just a small game for some friends, that makes heavy use of an object tree for managing the game world. I’ve found that initial world loads from a database on system startup is tricky, because of the recursive nature of the hierarchical structure. I had seen the original MagLev demo and realized that it could provide a reasonable mechanism for reading and writing large object graphs like the one in my game from a persistent store on disk, clustered using Terracotta.
I see two main obstacles so far, but this is only speculation because I haven’t managed to get JRuby to work with Terracotta for anything other than POJOs and Java Strings (instantiated inside the JRuby Runtime).
First, JRuby objects should be persisted into Terracotta automatically while configuring Terracotta to ignore any references to the JRuby Runtime instance itself, or its class loader.
Second, “transactions” would have to be managed automatically for specific object operations or entire instances of classes. This could be configured either by possibly annotations or maybe a DSL. Or some convention could be arranged. Such transactions would require that a write operations requiring immediate consistency be completed for every Terracotta instance in the cluster, or at least for a “master” node where an application could go to get guaranteed consistent data. Unfortunately, that node’s SLA would be limited. Other nodes could be written to ASAP for eventual consistency in the system.
Certainly there are tons of issues that would need to be addressed for any system resembling a highly available and scalable application. But these things would be a start, and would allow two things: The use of a highly scalable platform for ruby web-application programming, and also the reduction of a traditional relational database model, which doesn’t lend itself to massively interconnected hierarchical trees of objects with highly variable typing.
Well, I didn’t think I’d wind up writing this much stuff in this comment. Thanks again for the work that you’ve been doing. It’s been inspiring and interesting. I hope it can soon be used for something very special.