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

JBoss Cache 2.1.0 Alegrias is in BETA1

JBoss Cache 2.1.0.BETA1 has just been released. This is an incremental release on the 2.x series.

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

Your feedback on this release is much appreciated!

Enjoy,

Manik Surtani

Manik Surtani @ GrailsExchange

Guys n' Gals,

I'll be speaking on Advanced JBoss Cache usage at Grails Exchange in London later this month. Grails Exchange runs from Wednesday the 17th of October to Friday the 19th of October, inclusive, and my talk is scheduled for Thursday the 18th of October, at 15:10.

I hope to cover an architectural and design overview of JBoss Cache, speak about how it is typically used in other applications and products, explain a bit about the new 2.x series APIs, and describe what we have in store for the future.

Hope to see you there!

Cheers,
Manik

Hudson at last!

So we've finally got a public Hudson instance running for JBoss Cache to replace CruiseControl, which went out with our migration from CVS to SVN. And what a long wait too - whew!

So at last, you can now view build status and test results on the JBoss.ORG public Hudson instance (now to get it to expose additional source analyses like FindBugs results, etc!)

Enjoy, people!
Manik

JBoss Cache 1.4.1.SP5 released

A service pack on JBoss Cache 1.4.1, SP5, has just been released, fixing 2 pretty important bugs. I'd recommend anyone on the 1.x series upgrade to 1.4.1.SP5.

The download is available on the JBoss Cache downloads page, and the docs on the JBoss Cache docs page. Talk about this release on the JBoss Cache user forums.

Enjoy,

Manik Surtani

Month of Bugs - results

The recently-run Month of Bugs has proved to be a very useful tool in helping get a lot of testing and hardening on the Habanero CRs leading up to releasing.

As promised, prize winners have now been contacted, and I'd like to thank you all for your valuable contributions and participation. I do see this mechanism as a useful and effective thing to do prior to major releases, and quite possibly something we'd repeat in the future. :-)

Cheers,
Manik

Full time dev on JBoss Cache

Red Hat has just hired contributor and committer Mircea Markus to work on JBoss Cache full-time. Much needed as well, given the roadmap for 2.1.0, 3.0.0, etc. :-)

Welcome aboard Mircea, viva "professional open source"!

Cheers,
Manik

Hidden gems in JBoss Cache 2.0.0.GA

JBoss Cache 2.0.0.GA is out and as you can see from Manik's last entry, we're already moving forward...and fast. Before JBoss Cache 2.0 is forgotten, let's have a quick glance at some hidden gems that came within it:

1.- Singleton Cache Store Functionality

Cache stores are backend stores for data handled within JBoss Cache. Until now, the main two strategies to configure these cache stores were:

• sharing a cache store between all JBoss Cache instances.
• each instance having its own cache store.
  

Each strategy has its own caveats. For example, what if an user wanted to use a file based shared cache store, but the file system (i.e. shared NFS) did not support concurrent access/updates to it? An alternative solution would have been to configure JBoss Cache so that for each instance to had its own cache store. However, the user would have gone from having to manage/maintain one cache store to having to maintain N cache stores. Singleton Cache Store functionality was designed and developed to respond to the demands of such end users.

When cache loaders, which interact with cache stores, are configured for singleton store, only the JBoss Cache instance in the coordinator of cluster interacts with the cache store. The rest of nodes replicate changes to the coordinator which is in charge of putting them in the store. When such coordinator leaves the cluster, or stops working, a new coordinator is elected which takes charge of communicating with the cache store. This allows for only one JBoss Cache instance to interact with the cache store at a time.

More information on Singleton Cache Store functionality and configuration options can be found in the JBoss Cache 2.0 documentation.

2.- Transforming Cache Loaders

In JBoss Cache 2.0, the format of the data stored in the File and JDBC cache loaders has been changed so that it uses the JBoss Cache marshaling framework, created to improve replication efficiency, to format data to be stored in these cache stores.

At JBoss, division of Red Hat, we think about our product's end users and when implementing such data format change, we realised that some of JBoss Cache's users might have populated cache stores in JBoss Cache 1.x format. Even though JBoss Cache 2.0 is a major release, we wanted to provide our a way to transform existing cache stores from 1.x format to 2.x format. Because of this, we created a set of one-off Transforming Cache Loaders whose job is:

• read data from cache stores the way we did in JBoss Cache 1.x
• write data to cache stores in JBoss Cache 2.x format.

Together with this, an example was created which recursively reads the contents of the cache store via these Transforming Cache Loaders, and stores the data read back into the cache store. Just run this example with the parameters of your cache loader and the entire cache store will be transformed.

The Transforming Cache Loaders, necessary libraries to understand JBoss Cache 1.x and example mentioned can be found within the JBoss Cache 2.0.0.GA distribution ZIP file that can be downloaded from here.

More information on Transforming Cache Loaders can be found in the JBoss Cache 2.0 documentation.

JBoss Cache changes

Since releasing Habanero, I've been busy changing a few things around the way the source tree is managed (it was getting pretty messy). Basically, a lot of this revolves around JBCACHE-1142 which involves a number of changes. Let's take these one at a time.


1. Source code repository

We've moved from CVS to subversion. Still hosted on JBoss.org though, the main driver behind this was to be able to move files and directory structures around and not lose revision history.

Details of how to access the new repository are on the JBoss Cache wiki - committer rights have been carried across from CVS.


2. Structure

We've split POJO Cache into a separate module for easier dependency management. So now jbosscache-core and jbosscache-pojo can be built separately. See the wiki link above for more details.



3. Build tool

We've ditched ant in favour of Maven2. This affects the way the project is built and the way deliverables are created, but makes dependency management that much easier. So after a few hair-tearing days getting it to behave just the way I wanted it, we're finally ready here. Details of how to use Maven2 to build JBoss Cache are in the README-maven.txt file in the src tree.


4. TestNG

We're in the process of ditching the ageing JUnit 3.8-based test suite in favour of one based on TestNG. The reason behind this decision is so we can group and parameterise tests better, so that more combinations are tested (E.g., a test can be annotated as transactional and using a cache loader, and the test will be run with every combination of cache loader and transaction manager configured in the suite). The end result here will be a much more robust and well-tested product.


5. Preferred distribution

While we will still upload ZIPs onto SourceForge, we're trying to encourage users to use JBoss Cache using our Maven2 repository (and snapshot repo), to make dependency management easier.

An important point to note is that we've also standardised the groupId and artifactId used to org.jboss.cache and jbosscache-core (or jbosscache-pojo) respectively.


6. JBoss Cache 2.1.0 Alegrias

I had asked for suggestions for naming JBoss Cache 2.1.0 on the dev mail list, and have decided on Alegrias, courtesy of Galder Zamarreno. From Galder's email:

It's a type of very spicy chilli pepper from La Rioja in Spain, the same region from which the best spanish red wine comes.

http://www.thetapaslunchcompany.co.uk/products/vegetables/COR2101

Alegrias means happiness in plural, but in this case, they're trying to highlight tears of happiness ;)

So with that, I'd like to thank everyone who helped with Habanero and look forward to your participation on Algerias.

Cheers,
Manik Surtani

JBoss Cache 2.0.0 (Habanero) in GA

Habanero's finally in GA. Thanks to everyone who waited patiently for this major release, and to everyone who contributed - in code, patches, docs, bug reports, suggestions, testing, everything.

A lot of credit goes to Jason Greene, who joined as POJO Cache lead midway during Habanero development. Without his efforts we wouldn't have a stable POJO Cache release!

This is a milestone for JBoss Cache, where we move to a new, much more flexible and powerful API, and better support for running outside of JBoss AS, either in standalone Java SE or other containers.

We will also soon be announcing winners in the recent "month of bugs" competition, so watch this space.

There is a brand new user guide and tutorial, please do give these a go even if you are an experienced JBoss Cache user.

Please visit the JBoss Cache downloads page, docs page and discuss this release on the user forums.

Enjoy!
Manik

JBoss Cache 1.4.1.SP4 released

We've just released a service pack release on eht 1.4.1 Cayenne series, with some pretty important bug fixes on concurrent node removal and creation when using optimistic locking as well as some pretty big cache loader concurrency improvements, backported from the 2.0.0 series.

I'd recommend anyone on the 1.4.x series to upgrade to this latest service pack - especially if you use optimistic locking!

The download is available on the JBoss Cache downloads page, and the docs on the JBoss Cache docs page. Talk about this release on the JBoss Cache user forums.

Enjoy!

Manik Surtani
Project Lead, JBoss Cache
http://labs.jboss.org/jbosscache

JBoss Cache 2.0.0.CR3 released

JBoss Cache 2.0.0.CR3 has just been released.

This release includes a fair number of performance and stability improvements in the 2.0.0 codebase, and includes a new annotation-based API for working with cache listeners.

Please refer to the User Guide on the JBoss Cache docs page for details of this new API.

And remember, the Month of Bugs is still running, with prizes up for grabs for the most valuable contributions to 2.0.0.GA.

The download is available on the JBoss Cache downloads page, and the docs on the JBoss Cache docs page. As usual, discuss this release on the JBoss Cache user forums.

Enjoy!

Manik Surtani
Project Lead, JBoss Cache
http://labs.jboss.org/jbosscache

Month of Bugs extended

Never mind the misleading name, the "Month of Bugs" for JBoss Cache will basically run all the way through to the GA date, which will probably be towards the end of July.

Just so people know that the competition is still open. :-)

Month of Bugs - June 2007

This weekend we've launched the Month of Bugs competition for JBoss Cache. With just over a month to go before the planned release of JBoss Cache 2.0.0 Habanero, we'd like to invite the community to take part in this competition.

Contributions are welcome in all areas including bug fixes, unit tests, documentation and wiki articles, with the best ones receiving prizes delivered on the date of the final release.

Do visit the JBoss Cache Month of Bugs page for details. Looking forward to your participation!

Cheers,

Manik Surtani
Project Lead, JBoss Cache
http://labs.jboss.org/jbosscache

JBoss Cache 2.0.0 enters CR2

JBoss Cache 2.0.0 Habanero has just been released as a CR2. I expect at least another 2 CRs before going GA, the last CR containing a GA of JGroups 2.5.0, with its impressive new "concurrent stack". (See JGRP-181 for details on this).

Over the weekend we will also launch the Month of Bugs for JBoss Cache 2.0.0 Habanero, where we hope to promote people downloading and using Habanero CRs in their environments and use cases, and feeding back as much as possible, to make the GA of Habanero rock solid. More on the Month of Bugs later.

One significant point about CR2 is that performance has been significantly improved. People have complained on the user forums that CR1 was considerably slower than the 1.4.x series (1.4.1 Cayenne, our fastest release to date), almost as slow as the 1.3.x Wasabi series. After extensive profiling, I'm happy to say that in the basic use cases and tests performed so far, Habanero CR2 outperforms Cayenneby almost 20%. I expect to publish more formal statistics comparing with Cayenne by the time CR3 is out.

So all in, an interesting release and you are encouraged to download and give it a go. The download is available on the JBoss Cache downloads page, and the docs on the JBoss Cache docs page. As usual, discuss this release on the JBoss Cache user forums.

Enjoy!

Manik Surtani
Project Lead, JBoss Cache
http://labs.jboss.org/jbosscache

Blogging on blogspot.com

Instead of blogging on my "official" company blog at JBoss - where I'd usually talk about stuff related to JBoss Cache and such tech related topics, I've decided to move to blogspot.com.

Why? Mainly because I like the editing interface. Also, because I reckon it will get more readership and articles will still be syndicated on the JBoss Cache page on JBoss.org.

Anyway, I've just set this up, real content is on it's way.

Cheers,

Manik Surtani
Project Lead, JBoss Cache
http://labs.jboss.org/jbosscache