I am over in the US through to Christmas and enjoying my second only Thanksgiving here. It has put me in a reflective mood. We have been hard at work on Ehcache over the last few months and I want to give everyone an update on some cool stuff coming out soon.
Ehcache-1.7.1
1.7.1 contains 15 bug fixes and improvements. That is quite a lot for an ehcache release, but reflects some serious time put in by the Terracotta Transparency Engineering Team, together with the impact of the large changes made in 1.7.0 when we integrated with Terracotta.
The biggest thing is that 1.7.1 is ready for some serious business. Start with local caching, and choose from Terracotta open source, RMI, JGroups or JMS for clustering and replication. RMI and JGroups work well up to around 20 nodes, and up to as much data as you can comfortably deal with in your local node, around 5GB in memory and more if you overflow to disk. If you need more than that, or your need coherence, or you need 99.99+ then plugin in Terracotta. This last one costs money, but it is worth it and cheaper and better than the competition. With that solution you can scale as far as you want. Literally. In the new year I plan on showing how to take this to a 1 Terabyte coherent cache with 99.999% availability and class-leading performance. In the marchitecture, we call this the Scale Continuum, because that is what it is.
The other really big thing is that 1.7.1 completes the modularisation that was started over a year ago. The other ehcache modules will all have new releases, many of these the first non-beta releases as modules, in the next few weeks.
Google App Engine
Back in June I made some tweaks to support Ehcache in Google App Engine. At the time I suggested how this could be used with JCache and Google’s cache infrastructure. Because of GAEs restrictions, it did not include CacheLoaders. In 1.7.1 CacheLoaders have been changed to support GAE. And now, with a contribution from Cedric Lime, the ehcache-googleappengine module has been created. That one is fully integrated. It uses Ehcache as a high performance in-process L1 cache and GAE’s cache infrastructure as an L2. Why is this cool? Ehcache is 3 orders of magnitude faster. This means your apps will be faster, will do far less network calls to the cache infrastructure and will cost you a lot less in data and CPU charges. And you can build your apps as you are used to
Grails becomes a first-class citizen
I am a big fan of Grails, as are my Terracotta colleagues. Ari Zilka, Terracotta CTO, ran into Graeme Rocher, the maintainer, a few weeks ago at SpringOne, and we thought it was high time we offer Grails first class support. With that in mind I have been working with Graeme, testing Ehcache 1.5, which is already included in Grails-1.1.1, but is not active by default. It all works great. There will be a new Grails chapter (yes, this is the link, but I have not quite put it up) in the Ehcache documentation on Grails, showing step by step how to get up and running with Ehcache and Grails in about two minutes, with a couple of config line changes. Of course, with ehcache-1.7.1, this means that the Grails is a first-class citizen and can use our technology to scale up to massive apps.
Coming in early 2010: a new unified Hibernate Caching Provider
Ehcache of course started life as the “Easy Hibernate Cache”, thus ehcache and we remain committed to being the very best Hibernate caching provider. Now just prior to Ehcache joining Terracotta, Terracotta released a killer provider. As well as integrating with Terracotta clustering, it uses bytecode manipulation to remove syncrhonization required by caching providers (not Ehcache) and screams. Now that we have two providers, and Ehcache is already integrated with Terracotta via the ehcache-terracotta module, we plan to simplify everyone’s lives and unify the two by making a new ehcache provider which will work with ehcache but also with Terracotta.
OpenJPA becomes a first-class citizen
With JPA 2 about to make it out the door, a lot of folks have been playing with JPA by using Hibernate through it, or by using DataNucleus in GAE (at least I have). Earlier this year Craig Andrews contributed a patch for OpenJPA. That was released a few months back as the ehcache-openjpa module 0.1. In the best open source tradition the idea was to release it and get feedback. Now, we have that feedback, including from OpenJPA lead Kevin Sutter, and we have been readying 0.2. Once again, as with the OpenJPA ehcache provider can take you all the way along the scale continuum. We should have this released in the next week.
Ehcache DX Monitoring and Management
A few months ago I used the MySQL Enterprise Monitor. It turned out to be very useful to debug a gnarly problem we were having. It got me thinking that Ehcache could do with its own monitor for the same reason. Given that it would need to collect data from each CacheManager in your enterprise, and that most operations monitoring tools charge per monitor, an Ehcache Monitor would also provide a cheap and convenient consolidation point for integration with those tools. Now, at Terracotta, we think that caching should be a first-class component of your architecture, and therefore it needs first-class tools.
A few weeks ago we put out our first beta of this product and have been getting feedback. With the first cut working I have been thinking the past few weeks that I need to instil my knowledge of every caching issue I have ever had to investigate, and all the ones I have helped others with, into this tool. In other words, give it the secret sauce. In my opinion this will make the tool invaluable for production Ehcache environments.
Here is a peek at what is getting added into the next cut:
- Simplified SLA monitoring, using our HTTP interface
- Statistics switchable between instantaneous and cumulative
- A week or two’s history, for comparative analysis, and for finding the dreaded issues in your new application release
- Graphing of numerous Cache Efficiency statistics
- Graphing of Full GC and other GC events. Why? Because this is critical for apps with large heaps, which caching apps have
- Graphing of actual and projected memory use for each Cache. Wow! This one will be great.
- Clear a cache in all nodes across the whole enterprise with one click. (This one would have been useful )
Ok, so those are features, but how will that work on the ground. Well, I have been thinking about that and here is just one use case.
A new system is put into production with Ehcache. After 3 months, the users notice that the system is getting slow. Operations sets up SLA-alerts on page response time which immediately fail. They then set up alerts on average get time of 100 ms on any cache in the app’s main cachemanager – which immediately fails. 2nd level support is contacted. The av get time graph for a series of caches are reviewed. com.company.process.domain.Country cache shows a get time of 300ms. The graph history which goes back 2 weeks shows that it jumped a week ago and a week and a half ago. The config on the config tab is checked and it is noted that the max elements in memory is set to 50. The statistics tab shows that there are 50 elements in memory and 2 on disk. The memory consumption tab shows that used cache memory equals max predicted memory for the cache. The 2nd level support checks with apps administrators and discover that the system has been rolled out to more countries and is now at 52, with more coming. Solution: up the maxElementsInMemory to > 52.
To get involved in helping us shape the Monitor, you can download the first cut here. If you do, ping us with your feedback and we will incorporate it in the next cut which we will be starting work on in the next week.
Anyway, as everyone can see, I have been up to a few things since I started working on Ehcache full-time a month ago. Look out for next year!
