The official JBoss Cache blog

JBoss Cache 3.2.4.GA released!

2010-04-23T13:51:00.002+01:00

Hi,

Today we've released JBoss Cache 3.2.4.GA which contains fixes in here. Note as well that a couple of days ago we released 3.2.3.GA which had fixed these other issues. If you're using the Expiration eviction algorithm, you'll be greatly benefited from these releases.

Finally, remember that JBoss has moved to a new Nexus based maven repository, so make sure you update your local Maven settings as per instructions here in order to retrieve the new JBoss Cache releases.

Cheers,

Galder

JBossCache3.2.3CR1 released!

2010-02-16T11:44:00.002Z

JBossCache3.2.3CR1 has just been released. It contains a single performance improvement[1] that significantly increases the throughput when JDBC cache loader is used under heavy load. Thanks to Nikolay Zamosenchuk for investigating and fixing this!

[1] https://jira.jboss.org/jira/browse/JBCACHE-1569

JBossCache 3.2.1GA released

2009-10-01T13:40:00.002+01:00

Hi,

This release includes mainly bug fixes and performance improvements. You can find a detailed list of all items included here.

Enjoy!

Release of JBossCache3.2.1CR1

2009-09-25T14:13:00.000+01:00

Hi,

JBossCache3.2.1CR1 [1] has just been released.
Besides other fixes[2], this includes the integration with jgroups 2.6.13.CR2.

Enjoy!

[1] https://svn.jboss.org/repos/repository.jboss.org/maven2/org/jboss/cache/jbosscache-core/3.2.1.CR1/
[2] https://jira.jboss.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10051&fixfor=12313922

JBoss Cache 3.2.0 Malagueta just released!

2009-08-24T11:00:00.004+01:00

Another major JBoss Cache release: say hello to Malagueta!

While this is primarily a bug fix release, I have decided to bump up the minor version number (3.1.x -> 3.2.x) due to library compatibility. JBoss Cache 3.1.x could only support JGroups up to and equalling 2.6.x. Due to dependence on certain JGroups classes, 3.1.x will not work with newer JGroups releases (such as JGroups 2.8.x).

JBoss Cache 3.2.0 adds the ability to work with both JGroups 2.6.x as well as 2.8.x and beyond, and as such is more future-proof. Visit JIRA for a full changelog of issues addressed in this release. Downloads and documentation are in the usual places.

Enjoy!
Manik

JBoss Cache 3.1.0 Cascabel in final release

2009-05-05T09:58:00.003+01:00

I've just released JBoss Cache 3.1.0.GA, codenamed Cascabel. The big feature in this release is non-blocking state transfer, which allows for state to be transferred to new joiners in a cluster without freezing the cluster. I blogged about non-blocking state transfer some months ago, here.

Other changes include some critical bug fixes such as JBCACHE-1490, JBCACHE-1496, JBCACHE-1507 and JBCACHE-1508. New features - in addition to non-blocking state transfer - include a new lock-per-Fqn scheme for MVCC, which provides greater concurrency than the striped lock mechanism at the cost of memory usage and a slight performance hit.

The complete list of JIRAs addressed is here.

Downloads, documentation, etc are all in the usual place.

Enjoy!
Manikc

Announcing Infinispan

2009-04-29T15:57:00.003+01:00

I'd like to announce Infinispan, the spiritual successor to JBoss Cache. Read all about it on the Infinispan blog. And for those of you wondering about the future of JBoss Cache, this is addressed in the Infinispan FAQs.

Also note that Infinispan 4.0.0.ALPHA2 is now available for download. Please give it a go, feedback much appreciated.

Cheers
Manik

JBoss Cache 3.1.0.CR1 released

2009-04-02T17:26:00.002+01:00

Announcing the first CR on Cascabel. Click here for the changelog, downloads and docs are in the usual places. Please grab them and provide as much feedback as possible, especially on non-blocking state transfer.

Cheers
Manik

JBoss Cache and the community

2009-03-26T10:15:00.003Z

Roberto Tyley, who provided an important fix to JBoss Cache's eviction queue processing code in JBCACHE-1473, has written an excellent article on open source, using the sources, finding, analysing bugs and contributing to the project. He also has an interesting use case for JBoss Cache, using the cache in front of a database on a high-volume site such as The Guardian, a major newspaper here in the UK. I encourage you to have a read, along with Frederik Johansson's article on using JBoss Cache for simulating distributed load for online gaming.

Does anyone else have interesting usage stories they would like to share?

Cheers
Manik

JBoss Cache 3.1.0.BETA1

2009-03-20T15:29:00.004Z

3.1.0's been somewhat delayed due to problems with Non-blocking State Transfer, but these have finally been overcome.

Here's a quick summary first. The first Beta of JBoss Cache 3.1.0 Cascabel is now available in the usual places (download, docs, forums). The main feature of Cascabel is Non-blocking State Transfer, a new and highly efficient state transfer mechanism. Also, since MVCC was introduced in JBoss Cache 3.0.0 Naga, lock striping was used for the write locks held by nodes. While lock striping is efficient, it always exposes a slight risk of deadlock. In Cascabel, we now offer a lock-per-Fqn option for MVCC, which is more expensive than striped locks but is guaranteed to be deadlock-free. In addition, there are a host of bug fixes across the board, so this is definitely a version you should upgrade to if you use JBoss Cache 3.0.x.

Now for the details, starting with Non-blocking State Transfer (NBST). NBST has certain pre-requisites, specifically, that you use MVCC for locking and that you use JGroups' STREAMING_STATE_TRANSFER protocol. NBST works by allowing state to be read, free of locks thanks to MVCC, streamed to the receiver, all the while allowing the sender to continue changing state. What is key is that the sender also maintains a transaction log for this period. Once the state is delivered to the recipient and applied, the transaction log is then also streamed across, until the transaction log reaches a predetermined, small size - or it is detected that the transaction log grows faster than it can be streamed. In either of these cases, a lock is acquired on all processing, causing the sender to block all new transactions for a short period while the last of the transaction log is streamed and applied. After this, both the sender and receiver release locks and start processing requests, the new joiner now at the same state as the sender.

The main benefit of this approach is that the sender is not blocked for the majority of the time while generating and streaming state (made all the more apparent when there is a lot of state to send) and the cluster proceeds to operate. Naturally, the implementation is a fair deal more complicated than what is described quite simplistically above, with a fair few more details and edge cases to be dealt with. :-)

NBST is disabled by default, but can be enabled by using a simple configuration switch (Configuration.setUseNonBlockingStateTransfer() or <stateretrieval nonblocking="true" />).

So do give it a whirl, feedback, as always, is appreciated.

Cheers
Manik

JBoss Cache 3.0.3.GA released

2009-02-24T10:07:00.004Z

Based on the CR I released 2 weeks back, I have just released 3.0.3.GA. I recommend that everyone who is on JBoss Cache 2.x and 3.x move to this release, it is the fastest, most stable release to date. This incremental release on 3.x contains the following bugfixes and feature requests:

[ JBCACHE-1470 ] Option to disable cache event generation for a cache operation.
[ JBCACHE-1468 ] JBoss Cache ignores transactions with STATUS_MARKED_ROLLBACK and auto commits data changes
[ JBCACHE-1469 ] DummyBaseTransactionManager behaves incorrectly with Status.STATUS_MARKED_ROLLBACK
[ JBCACHE-1473 ] Memory leak: Cache Regions lose capacity, evictCommand.perform() causes dead entries in EvictionQueue
[ JBCACHE-1474 ] Removing nonexistent key in UnversionedNode causes data loss
[ JBCACHE-1477 ] Bug in JDBC cache loader SQL on Informix
[ JBCACHE-1478 ] Handle querying node count in an unstarted DataContainer
[ JBCACHE-1479 ] Loads nodes from cache loader too aggresively
[ JBCACHE-1480 ] getChildrenNames() returns deleted nodes
[ JBCACHE-1481 ] Re-adding a node deleted via parent inside transaction breaks the parent
[ JBCACHE-1471 ] Slow cache.get for fqn with a large number of key/value entries.

Thanks to Krzysztof Sobolewski, Roberto Tyley, Eduardo Martins, Galder Zamarreño and Alex Kluge for useful bug reports, tests and patches.

Downloads and documentation are in the usual place, please use the user forums to discuss this release.

Enjoy!
Manik

What to expect in JBoss Cache

2009-02-13T15:32:00.004Z

So we're about to cut JBoss Cache 3.1.0 "Cascabel" - and the main feature here is the high-performance non-blocking state transfer (NBST) scheme we've been planning for a while now, held back due to the lack of non-blocking reads in the past. Thanks to MVCC, we now have non-blocking reads, and thanks to Jason Greene, an impressive non-blocking state transfer implementation. Expect a beta of Cascabel to be made available in the coming days/weeks, along with a detailed write-up of NBST.

But in the meantime, I've just cut JBoss Cache 3.0.3.CR1. This CR fixes a number of bugs - some critical - on Naga, and I strongly recommend anyone using Naga to download and test out 3.0.3.CR1. I expect this to be a very short CR cycle so please test heavily and provide as much feedback as you can, I expect a 3.0.3.GA to be released very soon.

You can download the CR in the usual place on SourceForge, or grab it from our Maven2 repository.

Cheers
Manik

JBoss Cache in load testing

2009-02-10T20:08:00.003Z

I'm always keen to know how the community uses JBoss Cache. I was recently pointed to an excellent article by Frederik Johansson who uses JBoss Cache to build a load test harness to simulate tens of thousands of players in high capacity multiplayer online gaming systems.

Check out his wonderfully detailed yet accessible article on his blog.

If anyone else has success stories they would like to share, I'd love to hear them.

Cheers
Manik

New maintenance release on 1.4.1

2009-01-26T11:06:00.003Z

I've just released 1.4.1.SP12, a patch release on "Cayenne", which is in maintenance mode.

This contains just one fix over SP11 - JBCACHE-1304 - a backport from 2.x, thanks to Brian Dueck who contributed the patch.

Downloads, etc. are all in their usual places.

Enjoy!
Manik

3.0.2.GA ready for download

2009-01-20T16:18:00.002Z

I've just cut 3.0.2.GA. Thanks to everyone for all the feedback on the CRs. This is an important micro release, addressing a number of bugs in 3.0.1.GA. For a full list, please visit JIRA for the release notes. In addition to bug fixes, this release comes with some performance (JDBC cache loader) and stability (TcpDelegatingCacheLoader) improvements, and a tighter overall memory footprint.

Thanks to several contributors, including Elias Ross, Jimmy Wilson, Galder Zamarreño, J. Baxter, Brian Stansberry and Krzysztof Sobolewski for submitting patches. Keep 'em coming!

Also, useful to note, the parallel test suite is finally in place as of this release. This cuts down our unit test time, running 3500+ tests takes under 10 minutes now. This is down from the 2+ hours it used to take. Thanks to Mircea Markus and Dominik Pospisil for getting this working; I know what a PITA it is debugging threading issues involving Maven Surefure and TestNG. :-)

Download 3.0.2.GA here (or our Maven2 repo), docs and the rest are all in their usual places.

Enjoy!
Manik

JBoss Cache 3.0.2.CR2 is out

2009-01-12T14:32:00.002Z

I've just released 3.0.2.CR2, possibly the final CR before I cut 3.0.2.GA. 3.0.2.GA will contain a handful of bugfixes on 3.0.1, including:

[ JBCACHE-1447 ] JDBM cache loader remove of the root childeren doesn't clear the data
[ JBCACHE-1450 ] putForExternalRead() doesn't use a 0 lock acquisition timeout with MVCC
[ JBCACHE-1452 ] JDBCCacheLoader Doesn't Work With Sybase
[ JBCACHE-1454 ] Memory leak in CacheStoreInterceptor
[ JBCACHE-1455 ] Rollback corrupts nodes loaded from cache loader
[ JBCACHE-1456 ] The root node starts with "children loaded" flag
[ JBCACHE-1457 ] TcpCacheServer: Listening thread should attempt recovery
[ JBCACHE-1459 ] FastCopyHashMaps misbehave when serialized and then deserialized
[ JBCACHE-1460 ] Inefficient remove() in JDBCCacheLoader

Please download this, give it a try and provide as much feedback as possible. Downloads are in the usual place.

Cheers
Manik

A New Year's present from JBCS

2009-01-04T22:33:00.004Z

Hey guys,

Been quite a while since my last blog but here's an important one. If you thought that you couldn't get enough presents from Santa or you're loving the January sales, well it's getting better now. JBoss Cache Searchable has just got its first GA.

I just want to specify now that you have to pass in your class array when creating your searchable cache. Otherwise it breaks due to changes made in Hibernate Search 3.1.0.Beta and GA.

Apart from that, nothing different externally - go out and download it from sourceforge and tell us all about it on the forums. If you need to, have a look at the wiki or the API documentation.

I know that several people are keen to know about a searchable-pojo cache. A quick update is that I'm working on that and should have a release out soon. I will keep you posted, so watch this space.

Thanks and happy new year!
Navin.

Another micro release on 3.x

2008-12-19T16:04:00.003Z

I've just released 3.0.2.CR1, and hopefully if nothing else crops up, 3.0.2.GA before the end of the year.

This release fixes 4 bugs, reported on 3.0.1.GA released a short while ago. Details of the bugs are here.

Please download and try out this CR, and provide adequate feedback on the user forums prior to my releasing a GA.

Cheers
Manik

New micro release on JBoss Cache Naga

2008-11-28T13:15:00.003Z

We've just released JBoss Cache 3.0.1.GA. This contains a few bug fixes and performance enhancements over 3.0.0, and is particularly relevant to you if you use asynchronous replication together with buddy replication. It is also relevant if you use passivation, or JMX reporting on Websphere or WebLogic.

For a list of the JIRAs fixed in this release, please click here.

This release can be downloaded here, documentation here, please discuss this release on the user forums.

Thanks to Dominik Pospisil and Brian Stansberry for helping with this.

Cheers & Enjoy!
Manik

JBoss Cache 3.0.0 goes GA

2008-11-19T21:14:00.002Z

This much awaited release is finally in GA, in both core and POJO editions.

Downloads are here, online documentation is here, the extensive JIRA changelog is here for core and here for POJO, and finally the user forums are here.

There are a lot of folk to thank for this release, in no particular order, Mircea Markus, Jason Greene, Dominik Pospisil, Brian Stansberry and Elias Ross.

Have fun!

Cheers
Manik

Yet another CR

2008-11-03T18:06:00.001Z

Yes, I know I promised 3.0.0.CR2 would be the last CR before going GA, but ...

I've just cut 3.0.0.CR3 with some minor fixes. Please check it out, test it as much as you can internally, and watch this space for a GA in the coming weeks. Everything is in their usual place.

Cheers
Manik

Final CR for Naga - with more benchmarks

2008-10-23T18:44:00.016+01:00

So I've decided to cut another CR on 3.0.0. I wasn't originally planning on it and this would have gone gold save for the fact that a few important JIRAs did get in, which have pretty significant impact on performance (going northwards, of course - JBCACHE-1419 is notable, which contributed to a huge performance boost on async replication).

Anyway, to cut a long story short, download this final CR here, provide feedback here. Changelog is in JIRA, and all-new documentation is also available at last. If all goes well, I hope to cut a GA towards the end of next week, so I would appreciate as much feedback as possible - both on the release, as well as the documentation, tutorials, sample configs, etc.

And now for the fun stuff - I've finally found the time to put together some replicated benchmarks, to go with the standalone benchmarks I published a while back.

Kit used

The benchmarks were run on Red Hat's lab cluster of 8 servers, connected via gigabit ethernet.

Quad-CPU Intel Xeon 3GHz servers with 4GB of RAM each
RHEL 4 x86_64 with kernel version 2.6.9-42.0.10.ELsmp
SUN JDK 1.5.0_11-b03 (32-bit)
Benchmarks generated using the CacheBenchFramework
A single thread on each server instance, reading 90% of the time and writing 10% of the time

NB: You can click on the images to download full-sized versions

Benchmark 1: Comparing 2.2.0 "Poblano" and 3.0.0 "Naga" (synchronous replication)

This benchmark compares 2.2.0.GA with 3.0.0.CR2, using synchronous replication and pessimistic locking (Poblano) and MVCC (Naga).

The performance gain is between 10 and 20% for synchronous replication, and a pretty consistent 20% when using buddy replication. A large part of this is MVCC locking, but also other improvements in the code base play a part, including more efficient marshalling.

The total aggregate throughput chart shows that buddy replication (still) scales almost linearly. Increasing cluster size directly benefits the overall throughput the entire cluster can handle.

Benchmark 2: Comparing 2.2.0 "Poblano" and 3.0.0 "Naga" (asynchronous replication)

This had to be a separate benchmark from the synchronous one since the throughput is so much higher than sync replication it made a combined charts unreadable!

JBCACHE-1419 is the main contributor to the phenomenal performance gains in async replication in Naga. For folks who use JBoss Cache with async replication, I strongly encourage you to give Naga a try! :-)

Benchmark 3: Competitive analysis

This is something a lot of people have been asking me for. For this benchmark, I've pitted JBoss Cache 3.0.0.CR2 against EHCache 1.5.0, Terracotta 2.5.0 and a popular commercial, closed-source distributed cache which will have to remain unnamed. I've called this Cache X in my charts. I've used synchronous replication throughout since this is all that Cache X supported.

Both EHCache and Cache X slightly outperforms Naga on a 2-node cluster (not so slightly with EHCache), but these quickly fall behind as the cluster size increases, particularly in the case of EHCache. This is also reflected in the overall throughput chart. Buddy replication still shows linear scalability.

All of these benchmarks are reproducible using the cache benchmark framework, but as with all benchmarks, these should be used as a guideline only. Real performance can only be measured in your environment, with your specific use case and data access patterns.

Enjoy!
Manik

Another day, another GA.

2008-10-22T10:35:00.004+01:00

2.2.1.GA is out, folks. This micro release adds some serialization/replication (JBCACHE-1382) and JDBCCacheLoader (JBCACHE-1414) performance improvements, and fixes a bunch of bugs reported against 2.2.0.GA.

Enjoy, everything (downloads, docs, forums, JIRA) is in their usual place.

Cheers
Manik

2.2.1.CR2 is out

2008-10-15T10:15:00.004+01:00

The 2nd and hopefully last CR on 2.2.1 has just been released. It is on the JBoss Maven2 repository and SourceForge, as usual. Specifically, these JIRAs have been addressed between CR1 and CR2.

In the meanwhile, I am just about to fly off to Krakow, Poland, to attend the Java Developer Day conference, where I will be presenting on distributed caching. If any of you will be around, looking forward to seeing you there!

Cheers
Manik

Minor release in Poblano - 2.2.1.CR1

2008-10-03T09:50:00.003+01:00

I've just cut 2.2.1.CR1, an evolution of 2.2.0.GA containing a few fixes around transactions and marshalling, and performance improvements in the JDBCCacheLoader. See this changelog for details.

Downloads, etc. all in their usual places, enjoy!

- Manik

First CR for 3.0.0

2008-09-29T08:50:00.000+01:00

Late Friday I cut the first CR for Naga - 3.0.0.CR1 is now in our Maven2 repo and on jboss.org for you to download.

There are a host of new features, fixed bugs and performance tweaks in CR1 - check out the release notes on JIRA for the details.

Finally, I would like to add that this is not strictly a CR in that I can't release this as a GA. The documentation - FAQs, user guide and tutorial - still needs to be brought up to date with all the new features in Naga, but apart from that, the code is ready for the prime time. Pending feedback, bug reports, and the like, of course.

So, please treat this release as something close to prodution quality and feed back as much as you can on the user forums - this is really important to us. What I am particularly interested to hear are, in addition to comments on new features:

Performance under load
Performance in large clusters
Backward compatibility against code written for JBC 2.x

I look forward to hearing from you!

Cheers
Manik

JBCS 1.0.0 CR1 powered up

2008-09-25T18:45:00.010+01:00

Hello hello all, I come out of the darkness for the first time in a couple of weeks: -

As the title suggests, the first release candidate for JBoss Cache Searchable is up and running - download here. Some of you who are more inquisitive might be wondering what's actually changed from Beta 1.

Here's what's new. The 2 iterator methods on CacheQuery - iterator() and lazyIterator() - both can be called with integer parameters. Your fetchSize - your object buffer. This doesn't mean that the method calls with no parameters won't work, that just delegates to the method with parameters and gives a default parameter of 1. If you're more interested and want to dig deeper, have a look on fisheye.

As usual, have a play around and if there are any problems, you can find me on the forums.

On the horizon, I'm looking at releasing a version of the searchable-cache that depends on JBoss Cache 3.0.0. Personally, I'm quite excited to see how searchable-cache performance will change when it's depending on 3.0.0. I will keep you updated :).

Thanks for listening,
Navin.

Caching, parallelism and scalability

2008-09-18T18:31:00.003+01:00

DZone have just published an article by yours truly on Caching, Parallelism and Scalability. Check it out!

http://java.dzone.com/articles/caching-parallelism-scalability

- Manik

Naga Beta1 - ready to rock and roll!

2008-09-03T15:00:00.001+01:00

I've got a number of treats for you guys today.

Firstly, I've just released 3.0.0 BETA1. The public API is finally stable and all major features are in. A few minor bugs and performance tweaks (and documentation) pending, this is pretty much what Naga will look like. Expect it to rock your world! ;)

Second, after much discussion with the community, I have decided to make Naga API compatible with 2.x releases (Poblano, Alegrias and Habanero). This means a somewhat more cluttered API and a pile of old, deprecated methods, but at least it means you can just drop in a Naga jar into an app compiled against 2.x and expect things to work. You could then update your code to use more "current" APIs at your leisure. Keep in mind though that Naga runs with MVCC by default. If you wish to use PESSIMISTIC locking (the previous default) please make sure you specify this explicitly in your config file.

Finally, at long last, I have pretty pictures for people. Benchmarks comparing 3.0.0.BETA1 against 2.2.0.GA (released just last weekend), and 2.1.1.GA. And, for kicks, against the latest EHCache release as well. So far I just have the standalone benchmarks. Expect replicated benchmarks coming your way very soon.

The release

So, lets get started. Download the release in the usual place, feedback on the forums please. The more feedback the better, it helps us make JBoss Cache a better product. The changelog is in JIRA.

Notable features include:

a new batching API (JBCACHE-991)
the ability to persist transient state upon startup when fetchPersistentState is false (JBCACHE-131)
redesigned eviction, where you can now provide not just policies on how to select nodes for eviction, but also how that eviction behaviour is manifested (JBCACHE-1398). In plain English, this means you can now set the cache up such that nodes are completely removed upon eviction.

Benchmarks, part 1 : Standalone (LOCAL mode) benchmarks

As for benchmarks, these were generated using the Cache Benchmark Framework that I wrote. I actually encourage people to download the framework and perform these benchmarks on their servers as well to help validate my numbers. The benchmarks were performed on the JBoss clustering lab, with the following configuration:

Server running RHEL 4 and Sun JDK 1.5.0_11 with default settings
Max heap size of 2GB
4 Xeon CPUs with 4GB of RAM

These benchmarks were measured using simple puts and gets on random keys and values, with 20% write and 80% read, using 25 concurrent threads. The test was performed over a sample size of 10 million operations.

Read (GET) performance
(smaller is better)

Write (PUT) performance
(smaller is better)

As you can see, JBoss Cache is still a very viable standalone in-memory cache, which is highly concurrent. With Naga, this is even more so, given the huge performance gains realised thanks to our MVCC implementation.

Expect to see replicated benchmarks here very soon. In the meanwhile, enjoy Naga's first beta and let us know what you think!

Cheers
Manik

Making Blogger easier to use

2008-09-03T05:19:00.002+01:00

For those of you who are annoyed by Blogger's tiny edit window, check out this excellent script that provides a full sized edit pane. It needs Firefox and the Greasemonkey plugin, and works like a charm. Finally - a full-sized editor pane! :-)

New GUI demo

2008-09-02T12:17:00.004+01:00

I've just released a new GUI demo for the core cache, based on the recently released Poblano (2.2.0.GA).

This is version 1.1.GA for the GUI demo, check it out here. Please report all feedback on the demo on the forums.

Enjoy!
Manik

Poblano goes GA

2008-08-30T03:34:00.004+01:00

After a pretty long gestation period and no less than 7 CR releases, JBoss Cache 2.2.0 "Poblano" is finally in GA.

2.2.0 is the recommended release for all 2.x users, as it contains a number of internal enhancements and performance improvements (particularly in replication).

It also contains a number of important bug fixes, and a few new features including an Amazon S3 cache loader implementation contributed by Elias Ross.

See JIRA for the complete release note report.

Downloads, forums, wikis are all in their usual places.

Enjoy!
Manik

JBCS Beta 1 released!

2008-08-21T06:53:00.008+01:00

Some of you who may have read this blog a few weeks ago might have been excited to hear about JBoss Cache Searchable. For those of you who don't know about it - it provides a query interface on JBoss Cache. That is to say, you can now search the cache!

Why is this so cool?

You don't need to hang onto your keys to get objects out of the cache. Plus, you can now get multiple results from the cache from searching (e.g. all people named "Steve") whereas traditionally you will only get a specific object out (e.g. "Steve Jones"). Previously, the major difference between a cache and a database was the fact that you could not query it - and we've just changed that :).

Beta 1 for JBoss Cache Searchable is now out, so have a look, play around and let us know what you think about it. For more information, look at the wiki. This is available for download on SourceForge.

Also, I got to make my first proper presentation about this ( wOOt!) and it was to a team of developers at Sri Lanka's biggest mobile phone network - Dialog. Yeah you guys may not have Sri Lanka pop into your minds for cutting-edge technology (even if you know where it is) but these guys do have about 4 million subscribers and may soon use JBCS on a multi-million dollar project to maintain subscriber profiles. I have attached a pdf version if anyone wants to have a look.

'Til later,
Navin.

JBoss Cache 3.0.0 "Naga" - first Alpha now available!

2008-07-17T17:13:00.004+01:00

So to follow up from my post yesterday on MVCC, I'd like to announce that 3.0.0.ALPHA1 - codenamed Naga after the Naga Jolokia pepper - is now ready for download.

This release, in addition to a few major features like MVCC and a new configuration file format, contains a number of internal refactorings which will improve performance and stability even on previous locking schemes.

Have a look at the complete changelog of what is included in 3.0.0.ALPHA1. If you are interested, visit our JIRA page to look at what else is scheduled for 3.0.0.GA as well and vote on things - it helps us organise and prioritise features.

As usual, the download is available on SourceForge and the forums are open for your comments. :-) Please do stress this release out with your performance tests, I'd love to hear how it deals with load and massive concurrency.

Cheers
Manik

Configuration changes in JBoss Cache 3

2008-07-17T12:47:00.016+01:00

JBoss Cache 3 comes with a new, improved layout of the .xml configuration file. Certain constraints were dropped (e.g. explicit mbean support from xml file), so we took a step forward an refactored the entire configuration to be more readable, concise and consistent.

Summary of changes

new elements were created to gather related configurations; many of the 2.x configuration elements are attributes of these new elements

xml schema file is shipped now to verify configuration correctness. Schema can also be used with editing tools and IDEs to make it simpler to write configuration files. The parser was also updated to validate against this XSD (validation errors are being reported in the logs)

we supply tools for converting from an old XML file format to the new one, so that one does not have to migrate the scripts by hand

we kept the old parser, so old style configuration files are perfectly supported (not recommended though, as there you cannot specify features like MVCC and custom interceptors)

Configuration API is unchanged, so if you used programmatic configuration in your code it will work just fine

all the time related configurations are now in milliseconds (old eviction configurations elements were in seconds). The XSLT script that transforms from old configuration file to new one know how to transform seconds to milliseconds, when necessary.

it is possible to configure custom interceptors declaratively, in the configuration file

Migration old files to new format

The distribution comes with scripts that will automatically handle the transformation. You can find them in 'DISTR_ROOT/resources/config-samples/config2to3.sh'
and equivalent script for DOS. Executing the script will provide usage and help.

More on the new elements...

The distributions comes with several sample configuration files (DISTR_ROOT/resources/config-samples) which are a good start if you need to write your own, customized configuration.
Below are snapshots from the new configuration file, followed by a description of their meaning.

<locking isolationLevel="REPEATABLE_READ" lockAcquisitionTimeout="10000" nodeLockingScheme="mvcc"/>

the cache will use an mvcc locking scheme (other possible values are 'pessimistic' and 'optimistic' with isolation level set to 'REPEATABLE_READ'

<transaction transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup"/>

specify a lookup class for the transaction manager.

<stateRetrieval timeout="20000" fetchInMemoryState="true"/>

This instance will retrieve state from other existing instance, having the given timeout.

<transport clusterName="JBossCache-Cluster"/>

specifies the JGroups cluster name and also uses the default JGroups configuration for transport.

<replication>
<sync replTimeout="15000"/>
<buddy enabled="true" poolName="myBuddyPoolReplicationGroup" communicationTimeout="2000">
   <dataGravitation auto="false" removeOnFind="true" searchBackupTrees="true"/>
   <locator class="org.jboss.cache.buddyreplication.NextMemberBuddyLocator">
      <properties>
         numBuddies = 1
         ignoreColocatedBuddies = true
      </properties>
   </locator>
</buddy>
</replication>

This is a synchronously replicated cache using buddy replication.
For using the cache in asynchronous invalidation mode that does not use replication queues, following configuration might be used:

<invalidation>
<async useReplQueue="false"/>
</invalidation>

If you want to use a local cache, you can do that by not specifying neither an 'replication' nor an 'invalidation' element.

<startup regionsInactiveOnStartup=”true”/>

the regions will not be active when the cache starts, so it will not respond to replication messages.

<serialization useRegionBasedMarshalling="true"/>

Tells the cache to use different cache loaders for different regions, when (de)serializing data.

<jmxStatistics enabled='true'/>

tells the cache to gather usage information and expose it as JMX statistics


<eviction wakeUpInterval="5000" defaultPolicyClass="org.jboss.cache.eviction.LRUPolicy" defaultEventQueueSize="200000">
<default>
   <attribute name="maxNodes">5000</attribute>
   <attribute name="timeToLiveSeconds">1000</attribute>
</default>
<region name="/org/jboss/data">
   <attribute name="maxNodes">5000</attribute>
   <attribute name="timeToLiveSeconds">1000</attribute>
</region>
</eviction>

This is an eviction configuration. Default policy and queue size (attributes of 'eviction' element) allows defining defaults value for subsequent regions. Also, the 'default' element defines cache wide eviction strategy, overridden on an region bases by following 'region' elements.


<loaders passivation="false" shared="true">
<preload>
   <node fqn="/"/>
</preload>
<!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
<loader class="org.jboss.cache.loader.JDBCCacheLoader" async="false" fetchPersistentState="true"
   ignoreModifications="false" purgeOnStartup="false">
   <properties>
      cache.jdbc.table.name=jbosscache
      cache.jdbc.table.create=true
      cache.jdbc.table.drop=true
      cache.jdbc.table.primarykey=jbosscache_pk
      ...
   </properties>
</loader>
</loaders>

This is an cache loader configuration for a shared JDBCCacheLoader, no passivation. The root node will be preloaded on startup, specified through 'preload' element.


<customInterceptors>
<interceptor position="first" class="org.jboss.cache.sample.AaaCustomInterceptor">
   <attribute name="attrOne">value1</attribute>
   <attribute name="attrTwo">value2</attribute>
   <attribute name="attrThree">value3</attribute>
</interceptor>
</customInterceptors>

This configures the addition of a custom interceptor to the interceptor chain, after the default interceptor chain for the current configuration is built. The custom interceptor must have setters corresponding to 'attrOne', 'attrTwo' and 'attrThree', must implement org.jboss.cache.interceptors.base.CommandInterceptor, must have an default constructor. Its location in the chain will be determined by the value of the "position" attribute".

MVCC has landed

2008-07-16T10:53:00.010+01:00

I will soon be releasing the first alpha on JBoss Cache 3.0.0 - codenamed Naga after the Naga Jolokia pepper, naturally keeping with the pepper-naming theme. This is an alpha and doesn't nearly have all of what the GA release will have, but it does have two very significant features which I would like to share with the world. One is MVCC, and the other is a new configuration file format - which I've left for Mircea Markus to talk about in his post.

UPDATE: This has now been released. See my post on the release.

So on with MVCC. This is something people have been waiting for, for a long while now. Historic locking schemes - pessimistic locking and optimistic locking - have always been somewhat slow, inefficient, and synchronization-heavy. So we've redesigned concurrency and locking in the cache from scratch and have MVCC. Our designs for MVCC have been online for a while now. I do need to update the design page with more implementation details though, which did differ slightly from the original designs.

Feature Summary

In a nutshell, MVCC is a new locking scheme (MultiVersion Concurrency Control, something that most good database implementations have been using for a while now). our implementation is particularly interesting in that it is completely lock-free for readers. This makes it very efficient for a read-mostly system like a cache. The summary of features are:

Writers don't block readers. At all.
Completely lock-free for readers.
Writers are fail-fast (so no DataVersionExceptions at commit time, like when using our old Optimistic Locking implementation)
Deadlock-safe (thanks to non-blocking readers)
Memory efficient since we use lock striping (for writer locks) rather than one-lock-per-node.
Write locks implemented using the JDK's AbstractQueuedSynchronizer - which makes it free of implicit locks and synchronized blocks.
Locks held on Fqns and not Nodes. Which solves problems with concurrent create-and-removes seen occasionally with Pessimistic Locking under high load.

So what does this mean to everyone? Basically, a much more efficient locking scheme (expect statistics and comparisons here soon), with all the best that the previous two locking schemes had to offer (fail-fast - PL, concurrent readers and writers, deadlock-free - OL).

Switching it on

In the upcoming alpha, you enable this by setting your node locking scheme to MVCC:

Configuration c = new Configuration(); c.setNodeLockingScheme(Configuration.NodeLockingScheme.MVCC);

MVCC allows two isolation levels - READ_COMMITTED and REPEATABLE_READ. All other isolation levels - if configured - will be upgraded or downgraded accordingly. There are a further two configuration elements for MVCC: concurrencyLevel and writeSkewCheck.

Concurrency levels

Concurrency level is a tuning parameter that helps determine the number of segments used when creating a collection of shared locks for all writers. This is similar to the concurrencyLevel parameter passed in to the JDK's ConcurrentHashMap constructor. Unlike CHMs, this defaults to 50 - and should be tuned accordingly. Bigger = greater concurrency but more memory usage - thanks to additional segments.

Write skews

A write skew is a condition where with REPEATABLE_READ semantics, a transaction reads a value, and then changes to to something based on what was read, but another thread had changed it between the two operations. Consider:

// start transaction

line 1: int counterValue = readSomething();
line 2: writeSomething(counterValue + 1);

// end transaction

Since MVCC offers concurrent reads and writes, thread T1 could be at line 1, another thread (T2) could be at line 2 updating the value after T1 has read it. Then when T1 comes to writing the value, this would overwrite the update that T2 had made. This is a write-skew.

Now depending on your application, you may not care about such overwrites, and hence by default we don't do anything about it and allow the overwrite to continue. However, there are still plenty of cases where write skews are bad. If the writeSkewCheck configuration parameter is set to true, an exception is thrown every time a write skew is detected. So in the above example, when T1 attempts to writeSomething(), an exception will be thrown forcing T1 to retry its transaction.

What about other locking schemes?

With our final release, we hope to make MVCC the default option. Optimistic and Pessimistic locking will still be available but deprecated, and will be removed in a future release based on the success of MVCC.

Great! Where can I get it?

I will announce the release on this blog soon. Once the release is available, please download it and try it out - feedback is very important, especially in highly concurrent environments under a lot of stress.

If you are that impatient, you're welcome to check out JBoss Cache core trunk from SVN and have a play-around. :-)

Cheers
Manik

JBoss Cache Searchable

2008-07-04T14:23:00.018+01:00

For those who don't know yet, I've been working on a GSoC (Google Summer of Code) project and is the integration package between JBoss Cache and Hibernate Search. Basically, this enables users to search through JBoss Cache using Hibernate Search. According to another Surtani at JBoss, it's a very cool project and as far as I'm concerned it's just a fun piece of code to be working on :). It's been an interesting, topsy-turvy ride over the past couple of months getting all this stuff to work - and is still not optimised, but that will be done over the next couple of weeks. Here is some basic information I copied out from the wiki.

About this package

The goal is to add search capabilities to JBoss Cache. We achieve this by using Hibernate Search to index user objects as they are added to the cache and modified. The cache is queried by passing in a valid Apache Lucene query which is then used to search through the indexes and retrieve matching objects from the cache.

Usage

How will I use jbosscache-searchable?

You can create an instance of a searchable-cache. People who use jbosscache-core frequently will find this quite easy as it is very similar to creating an instance of the cache.

The SearchableCache interface is a sub-interface of Cache. Hence, it has the usual put(), get() and remove() methods on it. However, it also has the createQuery() method. This will return a CacheQuery object with which the list() method can be called. This will return all the results from the search in a list. You can also call an iterator() method on it - which returns a QueryResultIterator which is a sub-interface of the jdk's ListIterator.

How to create a searchable cache, code example: -

Start by creating a core cache.

Cache cache = new DefaultCacheFactory().createCache();

Similar to that create a searchable cache. As parameters, you must pass in the cache instance that you have created and the classes that you wish to be searched.

SearchableCache searchable = new
SearchableCacheFactory().createSearchableCache(cache, Person.class);

Lets say that I have 100 objects in this class and I want to search for the people with name John.As with Hibernate Search, create a Lucene query and a QueryParser.

QueryParser queryParser = new QueryParser("name", new StandardAnalyzer());

"name" is the field within Person that I want to be searching through.

Query luceneQuery = queryParser.parse("John");

"John" is the word within the name field that I want to be searching for.

CacheQuery cacheQuery = searchableCache.createQuery(luceneQuery);

The cacheQuery object will now have all the instances of Person with name John. I can now put all of these into a List: -

List results = cacheQuery.list();

Annotations on your classes.

For the classes that you want to be searched, you will have to annotate them with Hibernate Search annotations.

@ProvidedId - Firstly, you should not annotate a field with @DocumentId as normally with Hibernate Search. The @ProvidedId is so that Hibernate Search will not expect a @DocumentId and will know that you will provide one later. This is to say that a class with @ProvidedId doesn't need a @DocumentId. Although at this point it has not been tested, a @DocumentId in a field which is in a class that has a @ProvidedId should not break your system. This is a class annotation.
@Indexed - This is so that Hibernate Search will index the class in Lucene and is annotated on the class.
@Field - Hibernate Search will put all class-fields with this annotation into the index. With each @Field, you must also specify that the ''store'' property is set to ''yes''. Otherwise the field will not be stored. For example: - @Field (store = STORE.YES)

Also see http://www.hibernate.org/hib_docs/search/api/overview-summary.html for more information on annotations.

For more information, see the wiki page.

CRs everywhere. POJO Edition as well.

2008-07-02T15:40:00.003+01:00

So there have been a whole host of CRs on JBoss Cache Poblano. We've been releasing a whole bunch of these fairly close to one another, and have finally come to a pretty stable and solid CR that may well be the last before GA. 2.2.0.CR6 it is - and you know where to get it.

In addition, after a long wait, we also finally have the POJO Edition catching up with the release numbers. jbosscache-pojo 2.2.0.CR5 has been released with a CR6 coming out pretty shortly. The wait, primarily due to dependencies on fixes and new features in javassist and JBoss-AOP, is worth it - POJO Edition now handles array interception, more of which I expect Jason to blog about shortly.

Since we are at the final stages of release candidates for 2.2.0, I urge you to download and try out this release, and feed back as much as possible.

Important links are as follows:

Enjoy!
Manik

"Distributed Caching with JBoss Cache: Q&A with Manik Surtani"

2008-06-17T16:19:00.002+01:00

InfoQ has just published an interview they did with yours truly on the above subject. Check it out! :-)

- Manik

Poblano CR2 out

2008-06-04T13:25:00.003+01:00

Marching steadily along towards 2.2.0.GA, we've just released 2.2.0.CR2. This CR is pretty complete, nothing outstanding, very stable and no known issues. The bext 2.X release we have done to date. :-)

I expect 2.2.0.GA to be out soon as well, provided there are no major issues reported with this CR. So this is your last chance to give 2.2.0 a sound thrashing before GA! So please download this, try it out, and provide as much feedback as you can!

Important links are as follows:

Enjoy!
Manik

Poblano's first release candidate now available

2008-05-20T10:22:00.004+01:00

After our recent announcement re: JBoss Cache 2.2.0 (a.k.a. Poblano) BETA1 being released, we've been working on further stability improvements, even more performance tuning, and a couple of bugs that needed fixing. Poblano is now a release candidate, so please download it and stress it out in your system. Feedback is hugely important to us.

Important links are as follows:

Enjoy!
Manik

JBoss Cache 2.1.1.GA released

2008-05-06T11:27:00.003+01:00

I've just released a minor version on 2.1.0 "Alegrias", with some pretty important bug fixes. These include:

[ JBCACHE-1329 ] double removal on optimistic locking leaving stale nodes
[ JBCACHE-1170 ] Leakage of marshalling region stored in ThreadLocal causes partial state transfer to fail when multiple regions present
[ JBCACHE-1309 ] Unguarded adding of nodes to workspace
[ JBCACHE-1310 ] Marshalling failure with optimistic PREPARE
[ JBCACHE-1325 ] ClassLoader and probable memory leak in ReusableObjectInputStream
[ JBCACHE-1326 ] TxInterceptor leaks MethodCall to thread
[ JBCACHE-1316 ] recycleQueue.put() could block forever halting evictions and eventually any replications

Other improvements include enhancements to configuration and performance:

[ JBCACHE-1315 ] Eviction inaccuracy
[ JBCACHE-1218 ] System property substitution in config file parsing

For a full list of JIRAs included in this release, please see the release note report. As this is the latest and greatest of JBoss Cache 2.X, I would encourage anyone who is using a 2.X release to switch to 2.1.1.GA.

Enjoy!
Manik

2.2.0 "Poblano" and the evolution of JBoss Cache

2008-05-02T15:56:00.015+01:00

So we've finally cut JBoss Cache 2.2.0.Beta1. This is meant to be a minor release on 2.1.0, with some new features (JBCACHE-1258 and JBCACHE-1320 - both involving better cleanup of buddy backup regions when buddy groups no longer exist or when data is gravitated away), and some bug fixes and minor enhancements. And, pretty severe internal refactoring.

Before I bore you with details, here's a summary. The refactoring has provided us with a much more flexible architecture, where everything is far easier to extend, build upon and unit test, and in the process we've gained on average a 15% performance increase over 2.1.0, based on your cache mode. Enough said. :-) Read on for gory details, or skip to the bottom for benchmarks download links and the like.

Now the gory details. The original architecture of JBoss Cache involved a CacheImpl class, which contained most of the core functionality, and a series of interceptors which added aspects such as replication, cache loading and locking among others. Invocations were made on CacheImpl (exposed via a Cache interface), which created an invocation object - a subclass of JGroups' MethodCall object - and passed it up the interceptor chain. The final interceptor would then invoke an internal method on CacheImpl via reflection.

This gradually simplified (in 2.1.0, Alegrias) to use a separate delegate class which implemented the Cache interface, which pushed an invocation up the interceptor chain to end up as an invocation on the CacheImpl, as well as a ComponentRegistry which managed lifecycle and dependencies between different components in the cache such as the BuddyManager, RPCManager, NodeFactory, Notifier, etc. and inject these into interceptors that declare their dependencies on such components. This made things a lot more flexible and extensible, necessary to develop the host of new features we have planned for upcoming releases.

With Poblano, we've implemented a design by Mircea Markus, which uses Command/Visitor pattern and double dispatch to achieve strongly typed callbacks into interceptors. This involves scrapping the CacheImpl altogether, and implementing each public API method as a VisitableCommand. VisitableCommands can be visited by interceptors (which now implement Visitor), each visitXXX() method on each interceptor receiving a strongly typed VisitableCommand implementation with strongly typed payloads and parameters. The final interceptor - the CallInterceptor - now simply invokes VisitableCommand.perform(). Commands also have all the knowledge they need on how to roll back, via a rollback() method, which removes the need for an undo log for each transaction. The modification list is adequate for performing rollbacks as well.

Apart from the minor gains in stronger type safety (no more casting of MethodCall arguments) and doing away with the need for reflection in the CallInterceptor, the primary benefit of this approach is much better code readability, maintainability and unit testability (how many "-ity"s can you use on once sentence?!). Interceptors and commands alike can now be isolated and unit tested, rather than end-to-end functional tests for every combination of configurations, and the overall architecture is much easier to work with when adding features.

In terms of backward compatibility, even with the new architecture this release is 100% compatible with other 2.X releases, in terms of wire protocol (a 2.2.0 cache instance can talk to a 2.1.0 one, thanks to a new Marshaller implementation that is aware of and can translate between commands and MethodCalls being replicated) as well as in terms of plugins and extensions. Custom interceptors extending the abstract (and now deprecated) Interceptor class will still work, although the preferred approach now is to extend CommandInterceptor and use the strongly typed callbacks.

And now for the big surprise - as I said before, the real goal behind this was to improve the architecture for ease of use, robustness and maintainability, and as long as we didn't regress in terms of performance, I would have been quite happy with things. After the last week benchmarking and profiling things, we've had a very pleasant surprise, with pretty interesting performance gains. I'll let the numbers speak for themselves - Mircea has published his benchmark numbers here, on this wiki page, along with extensive information on how the test was run. Along with pretty charts. We all like pretty charts. :-)

So Poblano is now available as a beta, and I would very strongly encourage everyone to download and try this out. We want to make sure this release works as well for everyone as we hope it will. Check out the release notes, userguide and javadocs and benchmarks while you download the release, and comment and feedback on the user forums!

Enjoy!
Manik

Patch release on JBoss Cache 1.4.1

2008-04-04T11:23:00.004+01:00

JBoss Cache 1.4.1.SP9 has just been released on SourceForge. This is a maintenance release containing a few fixes. Visit JBoss Cache's JIRA page for details on what's been fixed in this release.

Thanks to Jimmy Wilson and Mircea Markus for pushing out this release.

It is recommended that anyone on 1.4.x upgrade to this release.

Cheers
Manik

JBoss Cache 2.1.0 "Alegrias" in GA

2008-03-20T17:20:00.005Z

The much-awaited JBoss Cache 2.1.0.GA release is now public and available.

In addition to a few bugfixes on 2.0.0, 2.1.0 adds a few new features such as a reconnectable TcpDelegatingCacheLoader, some new API convenience methods (reminiscent of the 1.x API), and a new notifier callback to inform listeners when a buddy group changes membership. And a lot of internal refactoring to make the code leaner, faster and more robust/maintainable. See JIRA for the full list of changes and enhancements.

Downloads are in the usual place. Everyone on 2.0.0 should upgrade - there are some pretty significant bug fixes here.

I must give special thanks to Mark Newton, JBoss.org's content lead who has helped with revamping the JBoss Cache documentation making it much more readable and easy to follow. Check out the very cool code-snippet syntax highlighting!!

Finally, a couple of things have changed with our user forums as well - there are now separate forums for Core and POJO editions of the cache; please use the relevant forum when discussing JBoss Cache. It helps us organise information better, helping you find stuff on older threads.

Enjoy!
Manik

New JBossCache release candidate

2008-02-22T16:01:00.005Z

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

Please do download and try this release out - it has substantial stability improvements, lot of it based on community feedback. Your suggestions are important to us, please join the user forums if you already haven't done so, and provide us with as much feedback as you can. Also don't forget about our Month Of Bugs!

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!
Mircea

Reusable object streams

2008-02-05T21:15:00.001Z

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

2008-01-28T10:28:00.000Z

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

2008-01-16T18:37:00.000Z

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

2008-01-16T18:30:00.001Z

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

2007-12-14T17:19:00.000Z

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

2007-12-12T11:20:00.001Z

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

2007-11-06T12:57:00.000Z

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

2007-10-18T13:26:00.000+01:00

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

2007-10-08T19:53:00.000+01:00

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!

2007-10-08T19:47:00.000+01:00

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

2007-09-28T12:10:00.000+01:00

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

2007-08-21T18:30:00.000+01:00

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

2007-08-21T16:55:00.000+01:00

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

2007-08-19T12:24:00.000+01:00

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

2007-08-15T13:50:00.000+01:00

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

2007-08-08T17:36:00.000+01:00

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

2007-07-27T15:49:00.001+01:00

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

2007-07-10T17:44:00.000+01:00

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

2007-06-29T13:03:00.000+01:00

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

2007-06-03T14:52:00.000+01:00

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

2007-06-02T00:50:00.000+01:00

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

2007-06-01T23:50:00.000+01:00

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