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.
The new ehcache server
Now, imagine several instances (behind the load balancer) running on terracotta servers with a shared heap…..
hi greg,
Good luck with this.
I’m also going through the same REST book. will be working on a JBoss related project with REST.
distributed ehcache : How about making a bundle with Terracotta + Glassfish ?
Thank you,
BR,
~A
Hi Anjan/Paul
Ehcache is already integrated with Terracotta. I worked with the Terracotta guys and made some changes to ehcache. They created a simple config. You can use Ehcache with replication handled by Terracotta.
As to a bundling it with the server, Terracotta is one of three replication choices with ehcache. And I am adding JMS in the next few months as a fourth option. I would rather leave it to the end user to configure their preferred replication scheme.
Maybe you guys can solve a bit of a technical riddle I’ve had running around my head regarding cache implementations and java.. In our application we have a variety of in process cache’s and are now exploring off process and off machine caching.
With the in process caching, we are running hard against the 32bit heap memory limits. We are planning on migrating over to 64bit JVM instances, *but*, everywhere I turn I hear dread warnings of GC interactions with 2GB+ heaps. In fact, one learned developer I follow suggested to never use a 64bit JVM for a cache server, and instead load balance however many 32bit instances it takes to get to your desired cache size. (Specifically saying that even if you had to run dozens of instances on a single box, it was worth it vs a single large heap 64bit VM)
So, I guess the question is, how does ecache, specifically the server version, handle cache sizes of 2,4,8 or more GB’s. Does it use any fancy memory tricks to help avoid killer GC pauses etc.
I was doing a thought experiment and maybe thought that using ASM or CGLIB (and an absurdly high permgen size), one could compile survivor cache entries into class bytes and push them into Perm space, essentially cloning a malloc/free in java.
Anyway, sorry for rambling on your blog, this is really, really awesome stuff. Thanks very much for pushing java scalability to it’s limits. You all rawk!! 🙂
-A
Adam
I have run ehcache in a 64 bit JDK with a 6GB heap for about 4 years now. I know of people out there running 15GB heaps.
Garbage collection can be very bad with large heaps. On my blog I have some magic settings I got from Sun which seem to work very well for avoiding Full GC pauses. I needed them for our app, which had a lot of cache churn.
I was surprised that the guy using 15GB did not need any special settings and did not have pauses.
So, I think it depends on your app. If you get into trouble try the settings I have. See http://gregluck.com/blog/archives/2006/07/how_we_solved_o.html
I am expecting people using the cache server to be running multi gigabyte caches.