Ehcache for JRuby/JRuby on Rails

I am pleased to announce that Dylan Stamat has just released Ehcache for JRuby.JRuby on Rails.

Quick Start

Following is a quickstart reproduced from his blog. HIs company is migrating from Ruby to JRuby and wanted to try in-process caching.
jruby -S gem install ehcache
manager =
cache = manager.cache
cache.put(“key”, “value”, {:ttl => 120})
An EhcacheStore is available for use within Rails, so all the native
Rails caching methods are supported. Make sure your config/environments/*,
are setup to support caching, eg: config.action_controller.perform_caching = true
1) From your RAILS_ROOT, run this command:
– ehcache rails ## just copies ehcache_store.rb into lib/ at the moment
2) In your environment.rb, specify:
– config.cache_store = :ehcache_store
3) Cache stuff

Q and A – Greg Luck and Dylan Stamat

Q: What are the reasons you are migrating from Ruby MRI (C Ruby) to JRuby?
A: There were quite a few reasons we decided to adopt JRuby, and probably like most
adopters, the deployment and applications options that became available were extremely appealing.
Our current stack is deployed on MRI, and runs pretty heavy. In some crude testing
of our application deployed to Glassfish, we had a significantly smaller footprint… and an
easier to maintain one at that.
Q: Ok, so why the move from memcached to ehcache? You can still use memcached from JRuby and that is the default cache most people use.
A: In the MRI world, we use memcached, which is a Ruby interface to the libmemcached C client.
It is one of the only Ruby libraries that currently supports consistent hashing, which is a requirement
for our production environment. When preparing for JRuby, we had a different set of options.
One was writing our own hooks into libmemcached via JNA, JRuby FFI, etc. The other was to look
for another cache solution in Java, and Ehcache was definitely on top of the list. We happen to have a
very read heavy application, and are not bound to using a distributed cache… so Ehcache seemed
like a very logical fit.
Q: How is JRuby packaged and what plans are there to keep the JRuby interface in sync with ehcache?
A: Anyone running JRuby, and needing a caching solution, should look at the Ehcache JRuby gem.
It’s a very simple interface to what Ehcache has to offer (which is a lot), and I would love to see it become an up-to-date mirror of the Ehcache project at some point. (Greg: Ehcache 1.5.0 got released just as Dylan was finalising the JRuby adapter)
Q; What are the production benefits of JRuby/Ehcache over Ruby MRI/Memcached?
A: I’m running the gem on a very low volume, internal system, and it definitely works like a charm… and am pretty confident that our current application is testing the limits of JRuby / MRI compatibility 😉
We currently have two bottlenecks on our JRuby initiative, one is getting our entire test suite JRuby compatible, which is proving to be a bit more involved than we thought. The other one was tracking down some intermittent marshalling issues we’re running into when using the Ehcache JRuby gem which we have just resolved today (Greg: 28 July 2008).
I’ll definitely try and get some sign off on using it (the intended production web sites) in the future so you can add them to your “who uses Ehcache” list in the future. (Greg: Suffice to say that the JRuby/Ehcache/Glassfish solution is intended to run some large public facing websites).

Project Details

Visit the project:
Google Group:
Bug Tracker:
And, a ticket system for the project here:
Will definitely get a ticket in there for updating it to use ehcache-1.5.0 😉

The new ehcache server

For those of you who do not know, the ehcache project has released a SOAP based server. It comes as a WAR which can be deployed to any web container. It also comes as a standalone server which uses Glassfish V3 embedded and can be started up with a simple script.
Why am I doing this? There are lots of theories that have made their way on to the ehcache mailing list. The prosaic truth is that a large US corporate using ehcache for their Java apps on 200+ servers also wants to use it for their C++ apps. And they are prepared to sponsor development. The Web Services API lets them do it. That’s it.
As to the larger question of how interesting this is to the world at large, my view is not very. However having to jump through all the hoops to get a server infrastructure done, I thought that the world at large may be interested in a RESTful, resource oriented ehcache server.
So, I am implementing the RESTful piece now. To me, this is pure exploration. I am on the journey and interested to see where it leads. I am using Jersey for this. Jersey and JSR311 are yet to be finalised. I have been logging bugs and interacting with the team as I go. They are releasing monthly, so I can release with a version of Jersey with all my bugs fixed.
I have a copy of Leonard Richardson’s and Sam Ruby’s book open in front of me. My aim to ensure that the ehcache server truly follows the resource oriented ideas in this book. Also that it honours ALL of the vaguaries of HTTP/1.1.
I expect to release the first complete RESTful implementation this weekend.
The conclusions I have right now:
1. Any language can use ehcache server. This includes C, C++, C#, VB, Perl, Python, Ruby, Scala, D …
2. There is no need to have a client per language. Because we just use HTTP, and almost all languages can do HTTP, we’re done.
3. Glassfish V3 uses NIO. The server performance should be awesome. Having said that, it will, as is memcached, two orders of magnitude slower than in-process caching, which uses references or pointers rather than network operations.
4. Ehcache server adds a few tricks due to HTTP. HEAD requests, conditional gets and expires headers. What’s faster than hitting a cache? Not needing to hit the cache at all. I am testing with curl, wget, various Java libs and browsers to make sure that this is done right. The combination of all these could massively outperform implementations like memcached.
5. Ehcache servers can be placed behind industry standard HTTP load balancers. You can have 2 or more of these in an ehcache cluster behind a single URL, offering load balancing and redundancy. So, if a single ehcache server dies, no problem.
The primary interest I have is providing a caching service which can act as a component in a RESTful resource oriented architecture. How far we take this will depend on who uses it and what they want.