Reusable object streams

In the process of profiling JBoss Cache internals prior to releasing another CR, I noticed that a lot of time was spent in the construction of ObjectOutputStreams and ObjectInputStreams. Especially wasteful since these streams are created for a very short while, just to be able to marshall an RPC method call to a byte buffer, to pass in to JGroups to replicate, or to unmarshall
a method call from a byte buffer on the other end.

Given that these streams have such a short life span, and are very frequently created and thrown away, pooling them is an obvious conclusion to come to. The problem is, JDK object streams make it very difficult to reset or reuse.

To overcome this, I have created my own set of streams - ReusableObjectOutputStream and ReusableObjectInputStream - that adds the ability to re-initialise the backing byte buffer. Which suddenly makes pooling possible. I can see why the JDK object streams do not allow reuse, since they could be backed by network streams that cannot be altered or reset, but in my case, since they are always backed by byte arrays, this is possible.

As far as JBoss Cache is concerned, I've had to add a few more configuration elements, with which to configure pool size and optimal default byte buffer size.

The code for these streams currently live in the JBoss Cache source tree. If there is any such use for such streams outside of JBoss Cache, let me know and perhaps I can package it as an independent library.

GUI Demo for JBoss Cache

So I've decided to try my hand at writing Swing code. For a guy who loathes writing GUI code, Swing is particularly painful, but IntelliJ's excellent GUI designer came to the rescue, taking away most of the pain. Sure, the generated code may not be optimal, but hey - this isn't a web browser I'm writing!

So on to the demo. The motivation for this demo is primarily the number of people that ask for a visual demo when I do presentations and talks on JBoss Cache or clustering in general. Everyone likes to see a demo, but JBoss Cache just isn't a visual product.

So that's what this demo tries to do - give JBoss Cache a "face".

The demo can be downloaded from the JBoss Cache download page on Sourceforge. The first release of the demo - 1.0-BETA1 - bundles JGroups 2.6.1 and JBoss Cache 2.1.0.CR3. Requirements are minimal - just a Java 5 JDK.

It should be pretty simple and straightforward to use - unzip and run the run.sh script to launch the GUI. The first thing you will see is an unstarted cache:


Once you click the Start Cache button, you should see the contents of the default configuration file used with the cache instance.



Note that this is a read-only display of the configuration file used. If you wish to edit this, exit the GUI demo, edit the config file in /etc/ and start the GUI demo again.

Now ideally you'd want to start several instances of the GUI demo, to watch them form a cluster and share data. The title bar of the application shows you the local instance's Cluster Address and the number of members in the cluster:


And once you have a few instances going, clicking on the Cluster view tab will show you the cluster's topology, indicating which instance is the JGroups coordinator, the current instance, and, if buddy replication is enabled, which instances are your buddy backups.

Finally, using the Manipulate data tab, you can either enter specific data, or generate random data, and using the Data view tab, watch how this replicates across your cluster.


Simple as that, really.

Enjoy playing around with this tool, and please provide feedback on the JBoss Cache user forums.

Cheers,
Manik

Another Month of Bugs

So after the overwhelming success of the last Month of Bugs competition we had (leading up to 2.0.0.GA) we'd like to do the same with 2.1.0.GA.

2.1.0.CR3 has just been released. It is faster and more stable than CR2, and we'd really like anyone using 2.0.0 to download and try out 2.1.0.CR3 instead. Try it in your test or staging systems, try it with your unit and stress tests. And let us know how it performs. Also, help us by going through the documentation, examples, everything, really - as far as the competition is concerned, every contribution counts, whether it is a bug, unit test, code patch, documentation edit, whatever.

As with the last time, there are some great prizes up for grabs such as gift vouchers, T-Shirts, etc., and we've also added @jbosscache.org email aliases to add to your geek credentials!

Please see the Month of Bugs page on the JBoss Cache website for details.

Happy hacking!
Manik

The first JBoss Cache release for 2008

We at JBoss Cache are proud to announce a third release candidate for Alegrias - JBoss Cache 2.1.0.CR3.

Please do download and try this release out - it has some substantial performance and stability improvements over CR2. Your feedback is really important in stabilising 2.1.0 - please join the user forums if you already haven't done so, and provide us with as much feedback as you can.

The download is available on the JBoss Cache downloads page, and the docs on the JBoss Cache docs page. The user forums are in the usual place.

Have fun!
Manik

New releases

Yes, I know I've been crap at announcing new releases, but in the past 2 weeks we've released a new SP on the 1.4.1 series as well as a new CR on 2.1.0.

2.1.0.CR2 is moving swiftly along towards GA, although I foresee at least 2 more CRs before release - this is going to be a rock-solid stable GA. I'm planning some pretty significant performance enhancements for CR3 as well, but please download CR2 for now and provide as much feedback as you can. It all helps.

1.4.1.SP8 contains some pretty significant bug fixes, particularly around buddy replication and optimistic locking. Please see the changelog for details.

Downloads on http://labs.jboss.org/jbosscache/downloads as usual, and the forums and JIRA are in the usual places.

Enjoy, and Merry Christmas.

- Manik

Republished: The Myth of Transparent Clustering

Since moving the JBoss Cache blogs to blogger.com, I've noticed that some of my old blogs on jboss.org seem to have disappeared. People have been specifically asking for this one, The Myth of Transparent Clustering - first published on jboss.org on the 5th of June 2006 and referenced by this TSS thread.

So here it is again, in it's original, unmodified form. Enjoy!

- Manik

I recently sat through a webinar by a certain unnamed vendor of Java clustering components, and was surprised to note that engineers experienced in the art of clustering Java applications still tout transparent clustering. It is one thing to see the concept of transparent clustering upheld by engineers whose core focus is not clustering, but coming from engineers who spend most of their waking hours focused on this task is another story.

Let's first explore what I understand to be - and what people seem to promote as - transparent clustering. In my mind, if clustering is to be truly transparent to your application - or more specifically, to you, the application's author - clustering should be enabled, configured, and tuned independent of the application, as a separate aspect. In addition, no changes in application design or implementation should be necessary for the application to be successfully clustered or for it to scale efficiently. Lets refer to these arguments as enablement and performance. In this article I only refer to the server-side aspects of clustering and not client-side code which needs to be able to fail over transparently.

Consider the first argument, enablement. Enabling, configuring and tuning the way your application is clustered in a transparent fashion is well within the grasp of what Java has to offer. Between XML configuration and annotations, AOP frameworks and runtime bytecode instrumentation, your code can be clean and have absolutely no dependency on clustering libraries or APIs. This is commonly called the API-less model. (In reality this is not completely API-less, as there will always be a dependency on an XML schema or annotations which, while may not be a compile-time Java dependency, still is a dependency on an API albeit a weaker one. I will not focus on this and am willing to overlook this dependency for the time being.). It is after achieving this that some stop, sit on their laurels and claim having achieved transparent clustering.

What is usually overlooked is the second half of my argument, performance, usually let down by not designing and implementing your application with clustering in mind. This is waved away as unimportant, that modern computing resources mean that 'minor inefficiencies' will not be a problem. Such wave-awayers obviously haven't heard of Sun Fellow Peter Deutsch's Fallacies of Distributed Computing. As much as people would like to think that with modern techniques like AOP, bytecode injection, annotations, along with a healthy dose of ignorance of reality, wishing upon a star and belief in the tooth fairy, clustering can be a truly decoupled aspect that can be applied to anything, they are wrong. I've heard a comment about JVMs handling garbage collection transparently and why clustering should similarly be as transparent. The bitter truth is that clustering can at best be thought of as half an aspect.

In a literal sense, with an API-less model, clustering can be implemented transparently. In all but the simplest of applications, though, this will not be sufficient to meet the goals of the clustering attempt without some consideration for clustering in the application. Large objects that need serialisation, considerations with use of transient and static variables, sub-optimal calls between layers of business logic, a tight loop of synchronisation can all lead to very inefficient clustering while these may be perfectly acceptable and performant in a standalone application. If your application wasn't written with clustering in mind, don't expect it to scale very well with the heavily promoted transparent clustering frameworks available.

So what does this mean for being able to cluster your application? Simple. Keep clustering in mind when designing it, even if there is no immediate requirement for clustering. It will save you the headache, cost and effort of refactoring your code at a later date when you find that your application does not scale as well as you thought it would. What about proprietary COTS applications, for which you don't have the source code? Well, let's just hope that your friendly neighbourhood proprietary COTS vendor had the foresight to design the application with clustering in mind!

--
Manik Surtani
Lead, JBoss Cache

New JBoss Cache releases

Over the weekend we've released JBoss Cache 2.1.0.CR1 (Alegrias) as well as a patch release on Cayenne, 1.4.1.SP6.

Anyone using the 1.4.x series, especially with buddy replication, is encouraged to upgrade to this patch release.

In addition, I'd encourage everyone to download and try out Alegrias, especially if you use 2.0.0 Habanero. Your feedback on this release is very important, as we hope this is a natural upgrade path from Habanero.

The downloads are available on the JBoss Cache downloads page, and the docs on the JBoss Cache docs page.

Enjoy,

Manik Surtani