Another micro release on 3.x

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

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

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

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

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.

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

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

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

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

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

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!

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

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

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

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!

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!

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

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

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

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.

1. @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.
2. @Indexed - This is so that Hibernate Search will index the class in Lucene and is annotated on the class.
3. @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.

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:

• Downloads
• Documentation
  
• Forums

Enjoy!
Manik

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

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

- Manik

Poblano CR2 out

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:

• Downloads
• Documentation
  
• Forums

Enjoy!
Manik

Poblano's first release candidate now available

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:

• Downloads
• Documentation
  
• Forums
• JIRA changelog

Enjoy!
Manik

JBoss Cache 2.1.1.GA released

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

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

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

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

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

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

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

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

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

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

GUI Demo for JBoss Cache

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

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

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

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

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


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



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

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


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

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


Simple as that, really.

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

Cheers,
Manik

Another Month of Bugs

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

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

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

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

Happy hacking!
Manik

The first JBoss Cache release for 2008

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

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

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

Have fun!
Manik