|
|
|
|
Back to newsletter 038 contents
This month we interview Bela Ban, the lead for the JBossCache project, targeted to be an efficient replicated cache.
JPT: Can you tell us a bit about yourself and what you do
I'm the lead for JGroups (www.jgroups.org) and the JBossCache (www.jboss.org). JGroups is a toolkit for reliable multicast in Java, and is the basis of JBoss Clustering and JBossCache. I was born in Switzerland, went to college at University of Zurich and completed my Ph.D. there. I also worked at IBM Research in Zurich for four years. Then I moved to the U.S., did a post-doc at Cornell, and then worked for Fujitsu Network Communications until 2003. I joined JBoss Group in 2003.
JPT: You've just released JBossCache, please tell us a little bit about the product?
JBossCache is a tree structured replicated transactional cache, which can be used to replicate data transactionally across process boundaries. So if you add an element to one tree, it will appear in all the trees in the cluster. A cache can either be local or replicated. In the replicated case, we can do asynchronous or synchronous replication, the latter blocks the caller until all trees in a cluster have been updated; the former simply puts the modification(s) on the bus and returns immediately, with replication going on in the background. JBossCache can be used transactionally, meaning that if you have a transaction, JBossCache will collect all modifications and only replicate at the end of the transaction. Of course, if you rollback the transaction, there won't be any replication. So, to summarize I would say there are three main modes JBossCache can be used in:
JPT: What prompted you into wanting to develop a caching product?
In Marc's blue paper, he mentions the need for a cache to speed things up. The main use-case is access to entity beans in a cluster. Today you have to use commit option B or C when you access entity beans in a cluster. Which basically means that, although you can have a cache, you have to remove the cached entity bean at the end of a transaction. This basically defies the purpose of a cache. So what we want to do here is to use our transactional replicated cache to actually keep the cached entity beans in memory. This will greatly improve performance, especially in applications that have a lot of reads. Writes are bundled and replicated at the end of a transaction between the caches, and of course also persisted to the database. We are currently using the Synchronization interface to let the transaction manager tell us when it is about to commit a transaction. In the future, we want to make that JBossCache a JCA ResourceAdapter, so we can also support distributed transactions. But we also have other use cases for the cache:
In general, there are a lot of different caches around in JBoss. JBossCache intends to unify them into a single cache, that we can improve centrally, so all subsystems benefit from the improvements. This is only possible because JBossCache can be configured to run in different modes.
JPT: What problems were you originally trying to solve with this product?
See above. The main problem was and still is the caching of entity beans across a cluster. However, I think that JBossCache is a useful piece of code in itself. You can also use it standalone outside the JBoss container .
JPT: Marc [Fleury] has claimed that this cache is the first distributed caching solution that will offer good performance for fine grained objects. Can you comment on that statement?
That's the goal. We are not yet there. Let me explain a little bit. The JBoss cache comes in two versions: TreeCache and TreeCacheAop. TreeCache is what I've been talking about so far. TreeCacheAop is a subclass of TreeCache, that uses instrumentation of class code to know when the state of an object has been changed. This allows us to track changes to objects in the TreeCacheAop, and only replicate the changes at the end of a transaction. So if you have a big object and only change a few bytes in the object, so far you would have had to serialize the entire object and send it across the wire, wasting bandwidth and CPU cycles for serialization. In the TreeCache AOP case since we track changes to this object, only the changes will be replicated. So this will give us good performance, and not because AOP is so fast (as a matter of fact field interception slows things down), but because we can reduce serialization and unnecessary network traffic.
Ben Wang (out of Cupertino Calif) works on the TreeCacheAop part, a very important part of JBossCache, so I'd also like to mention him here.
JPT: In any project, we always guess at where the performance bottlenecks will lie, what were your guesses and did they turn out to be bottleneck?
Well, of course 2 phase commit is always costly. Another bottleneck is that if you access the same objects in different trees within the same cluster, you might run into deadlocks. We solve this problem by a using lock acquisition timeouts, so that one of the two transactions that access the same object at the same time will rollback, and the other one will succeed. But in the long run we would like to come up with a scheme where we provide a distributed deadlock detection mechanism, which is not trivial though.
JPT: Can you tell us about any unexpected bottlenecks that you encountered?
We didn't really discover any unexpected bottlenecks. One of our unit tests failed once because of the timeout, and we realized that we had made 500 modifications to a replicated tree but each modification was wrapped in a transaction between an commit. This of course caused 500 2 phase commit protocol runs which really brought us down. This is not really an an issue with the TreeCache though, but with the way we used it.
JPT: You will be going to HP labs to do some performance tests. This is an interesting choice, can you tell us a little bit about it?
Well, HP Professional Services are seeing a lot of their customers using JBoss, and so naturally they want to be able to provide support for JBoss, and be able to fix performance problems themselves before they get back to us (JBossGroup). So they offered us to use their performance labs. Initially we will test JGroups and the JBossCache, but we are also interested in testing the JBoss Clustering .
JPT: What type of benchmark do you plan on using while at HP? Why type of results are you looking for?
Well, with respect to JBossCache: we will have a cluster of 4 nodes and run test drivers on each of them. Each test driver makes a large number of modifications to the cache, and at the end of the test run, all 4 nodes should have the same state. This allows us to test for both reliability and correctness of the JBossCache, and also for performance bottlenecks. With respect to JGroups: we intend to increase the message rate from hundreds per second to the lower thousands per second.
We also intend to test larger clusters: maybe up to 20 physical machines. Also, we will test on:
JPT: If you had the power to change one thing in Java, what would that change look like?
I'm pretty happy with Java, and I think SUN has done a good job. A couple of minor things though:
Thank you for your time, Bela.
(End of interview).
Back to newsletter 038 contents
