Infinispan

Participating at Miralce Open World 2012

2012-02-22T10:46:00.005-08:00

I'll be presenting at this year's Miralce Open World with a talk on how Radargun is used for measuring Infinispan's performance. I think the topic is interesting for anyone that needs to prototype applications built using in-memory datagrids such as infinispan.
So if you are around and you are interested in this topic, or just want to say hi, then look for the guy with the Infinispan t-shirt (and my name on the badge)!

Cheers,
Mircea

More feedback needed! Remote events coming to Hot Rod

2012-02-20T06:40:00.000-08:00

With 7 votes already, remote event handling in Hot Rod is one of the most demanded features in Infinispan, and we've just started designing it. You can find out more about the design in this article and I've also started a Infinispan Development mailing list discussion in order to open a debate on this article.

Remember that remote event handling is the key piece that allows near-cache like patterns to be built in Infinispan and we know for a fact that this is one of the most demanded Infinispan patterns. So, if you have an interest in near caches, please provide any feedback you might have on the kind of event subscriptions and notifications you're interested.

To provide feedback, either comment on the linked article, or join Infinispan's Development mailing list and reply to the mail thread.

Cheers,
Galder

Cross-datacenter replication: your feedback is needed!

2012-02-13T09:40:00.000-08:00

Hi,

Cross datacenter replication has been for a while one of the most requested features in Infinispan. In order to support this as good as possible we are looking for as many use cases that require this functionality. So if you've ever came to this problem or you think you will, or you simply feel like brainstorming about an interesting failover situation please add your comments here.

Thank you,
Mircea

Infinispan 5.1.1.FINAL is here!

2012-02-03T04:09:00.000-08:00

As said earlier this week, based on the feedback we got, we decided to cut a point release in the 5.1 'Brahma' series, and following Tuesday's CR1 release, I'm really please to announce the release of Infinispan 5.1.1.FINAL. If you're using 5.1.0.FINAL or any other pre-releases, I'd strongly recommend that you upgrade to this version.

Full details of what has been fixed can be found here, and if you have feedback, please visit our forums. Finally, as always, you can download the release from here.

Cheers,
Galder

Infinispan 5.1.1.CR1 is out

2012-01-31T07:01:00.000-08:00

Thanks to everyone that downloaded Infinispan 5.1.0.FINAL 'Brahma' in the last week. We've had tremendous feedback from the community and as a result we've decided to do a minor release called 5.1.1.CR1 to address the most important issues reported. So, if you're using 5.1.0.FINAL, I'd strongly recommend that you upgrade as soon as possible. We hope to do a FINAL release later on this week.

Please keep the feedback coming, and as always, you can download the release from here.

Cheers,
Galder

Manik's take on JUDCon India

2012-01-26T07:31:00.001-08:00

JUDCon has, for the first time ever, spread beyond the western world. JUDCon India, held on Tuesday and Wednesday this week, was a roaring success with over 800 passionate community members flocking to the event held in Bangalore, India's answer to California's silicon valley.

View Larger Map

One of the themes was developer productivity and engagement, to help community members get more involved in the projects they care about, to help them succeed in their businesses with JBoss technology.

JBoss AS 7, NoSQL and platform-as-a-service were a few of the popular themes, and there were no less than 6 talks on infinispan in just two days, presented by myself and Galder Zamarreño. The talks ranged from high level overviews and roadmaps to detailed, hands-on hacking sessions, as well as presenting thoughts and ideas for future development.

All in, an excellent community conference, well organised by Saltmarch Media, and very well received by the community. I for one look forward to another JUDCon in Bangalore in the hopefully not too distant future.

Cheers
Manik

PS: After writing this, I noticed that Galder has blogged about JUDCon India too!

JUDCon India post-mortem

2012-01-25T11:40:00.000-08:00

JUDCon India is finished now and I was hugely impressed with what I saw in the conference. First of all, it was by far the biggest crowd I've seen in a JUDCon event so that's excellent news. The more, the merrier :)

The attendants have been excellent and in general I felt that they were paying more attention than in conferences in other countries. This is partly because hardly any attendant had their laptops open while listening to the presentations. They simply had a notebook and a pen or pencil and they were taking just notes. I wished this would happen more often in other conferences. Hmmm, time to ban laptops in non-interactive presentations?

I ended up doing 4 presentations, 3 of them in Infinispan related topics and 1 talking about JBoss Polyglot. Of all, the one that I felt attracted the most attention was the one on near caches. I got a lot of positive feedback from attendants and very interesting questions at the end of the presentation.

In terms of organization, it was impecable. Wifi worked like a treat with around 7 access points, 3/4 of which you could join from any place in the conference. Food was good as well, if you like Indian cooking of course :). As I already said on Twitter, the toilets were... interesting for a westener :).

Finally, I must congratulate the organisers on the method used to motivate attendants to provide feedback on the presentations. To get the JUDCon t-shirt, attendants needed to fill in feedback forms for all presentations they had attended, and once the last presentation had finished, they could go and claim their t-shirt once they'd handed over the feedback forms. I thought this was a fantastic idea to increase the amount of feedback received. So, well done to organisers! Looking forward to reading the feedback now.

Just landed in Delhi and now waiting for my colleague Rado, who's arriving in a later flight from Bangalore. It's time now for a couple of days off and doing a bit of touristy stuff around here. Plenty to see and do in the next few days with the Republic Day military parade, visit the Red Fort, Taj Mahal...etc.

Cheers,
Galder

Infinispan 5.1.0.FINAL is finally here!!

2012-01-24T10:06:00.000-08:00

After over 4 months of development, testing, profiling...etc, I'm extremely pleased to announce that Infinispan 5.1.0.FINAL 'Brahma' is out now! It comes with some very important brand new features such as:

We've also implemented a bunch of improvements such as:

This has been a huge effort by all the Infinispan community including forum users, which have been giving us tremendous feedback, occasional community contributors and core developers. Thank you very much for all the effort you've put in!!

We've build a migration guide for anyone upgrading for 5.0.0.FINAL to 5.1.0.FINAL, so make sure you read it if you're upgrading.

As usual, download the release, provide feedback, read through the detailed changelog. And check out our documentation for this version too.

Cheers,

Galder

Infinispan coming to India!!!

2012-01-19T08:33:00.000-08:00

Next week Manik and I will be representing the Infinispan contingent at JUDCon India in Bangalore and we have plenty to talk about:

Tuesday, 24th January

Infinispan: The Path Ahead - Manik
Extreme Performance and Scalability with Infinispan Near Caches - Galder
Building a Transactional, Scaled Application Using Infinispan and Java EE - Galder

Wednesday, 25th January

Technical Deep-dive with Infinispan - Manik
Eventual Consistency in Infinispan - Manik
Infinispan In 50 Minutes - Galder

Finally, to top it up, I'll be doing a presentation on JBoss' Polyglot revolution!

This is going to be my first visit to India and I'm very excited to be presenting at this conference :). Looking forward to meeting developers, architects and in general, anyone interested in data grids and various NoSQL technologies next week.

Cheers,

Galder

Infinispan 5.1.0.CR4 is out!

2012-01-17T03:19:00.000-08:00

Over the past week we've been busy profiling Infinispan, in particular we've been trying to maximise the performance of Infinispan transactional caches which received a major overhaul int the 5.1 'Brahma' series, and the result is that instead of going final, we've decided to cut another candidate release, Infinispan 5.1.0.CR4 which is now available for download from the usual place. We're confident that these improvements will be greatly appreciated by Infinispan consumers such as Hibernate second-level-cache and JBoss Application Server 7 HTTP session replication.

As part of the configuration and parser work, new configuration documentation has generated which you can now find in http://docs.jboss.org/infinispan/5.1/configdocs/.

As always, give it a spin to this new candidate release and let us know what you think. You can find detailed information on the issues fixed in our release notes.

Cheers,
Galder

Last Infinispan 5.1 'Brahma' CR is out!

2012-01-10T00:57:00.000-08:00

First of all, happy new year to all the Infinispan community!

The final CR of the Infinispan 5.1 'Brahma' series, called 5.1.0.CR3 is out with another round of fixes. This will be the last of the candidate releases and we expect to go final with the release very shortly, so your help now is crucial. If you're using the last of our stable releases, 5.0.1.FINAL, please upgrade to 5.1.0.CR3 and let us know if you encounter any issues.

Cheers,
Galder

Configuration Changes in Infinispan

2012-01-04T09:52:00.000-08:00

This blog will introduce both Infinispan users, and Infinispan contributors to the new configuration system. First, I'll detail the changes for users, and then for committers.

Users

If you use XML to configure Infinispan, you shouldn't notice any change, except a much faster startup, courtesy of the Stax based parser. However, if you use programmatic configuration, read on for the important differences.
Configuration is now packaged in org.infinispan.configuration, and you must use a builder style:

Configuration c1 = new ConfigurationBuilder()
   // Adjust any configuration defaults you want
   .clustering()
      .l1()
         .disable()
      .mode(DIST_SYNC)
      .hash()
         .numOwners(5)
   .build();

The old bean style configuration is now deprecated and will be removed in a later version.
Configuration properties which can be safely changed at runtime are mutable, and all others are immutable.
To copy a configuration, use the read() method on the builder, for example:

Configuration c2 = new ConfigurationBuilder()
   // Read in C1 to provide defaults
   .read(c1)
   .clustering()
      .l1()
         .enable()
   // This cache is DIST_SYNC, will have 5 owners, with L1 cache enabled
   .build();

This completely replaces the old system of defining a set of overrides on bean properties. Note that this means the behaviour of Infinispan configuration is somewhat different when used programmatically. Whilst before, you could define a default configuration, and any overrides would be applied on top of *your* defaults when defined, now you must explicitly read in your defaults to the builder. This allows for much greater flexibility in your code (you can have a as many "default" configurations as you want), and makes your code more explicit and type safe (finding references works).

The schema is unchanged from before. Infinispan 4.0 configurations are currently not being parsed. Support for these will be added shortly, however a warning message will be printed if they are used. To upgrade, just change the schema definition from:

<infinispan
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:infinispan:config:4.1 http://www.infinispan.org/schemas/infinispan-config-4.1.xsd"
     xmlns="urn:infinispan:config:4.1">

<infinispan
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:infinispan:config:5.1 http://www.infinispan.org/schemas/infinispan-config-5.1.xsd"
     xmlns="urn:infinispan:config:5.1">

The schema documentation has changed format, as it is now produced using the standard tool x3p. This should be a significant improvement, as better navigation is offered. Some elements and attributes are missing docs right now, we are working on adding this. As an added benefit, your IDE should now show documentation when an xsd referenced (as above)

We are in the process of adding in support for this configuration style for modules (such as cache stores). In the meantime, please use the old configuration or XML if you require support for cache store module configuration.

Committers

If you are a committer to Infinispan, you may find the following notes useful. Note that currently we still use the old configuration system internally within Infinispan. This makes things a little complicated. This will be switched out soon! For now, you need to also add your property to the old config system as well as the new.

Note, these guides assume you are adding an element to the cache configuration, but apply equally to the global configuration.

Before you start adding a configuration property, identify whether you want to add a property to an existing configuration group/element, or whether you need to create a child object. We call the configuration group XXX in the steps below.

Adding a property

Add the property to the relevant XXXConfiguration class. Add a private final field, add a parameter to the constructor, and assign the value to the field in the constructor body. Add a accessor for the property. If the property should be mutable at runtime, then add a mutator as well. Most configuration properties are not mutable at runtime - if the configuration is runtime mutable, then Infinispan needs to take notice of this update whilst the cache is running (you can't cache the value of the configuration in your implementation class). Mutators and accessors don't use the classic JavaBean pattern of prepending accessors with "get" and mutators with "set". Instead, the name of the property is used for an accessor. A mutator is an overloaded version of the accessor which takes a parameter, the new value.

Add the property to the matching XXXConfigurationBuilder. You'll need to add a mutable field to the class, and initialise it to it's default value in the field declaration. Add a mutator (following the above pattern).

The create() method is called by the parent object in order to instantiate the XXXConfiguration object from the builder. Therefore, make sure to pass the value of the field in the builder to the XXXConfiguration object's constructor here. Additionally, if you require a complex default (for example, the value of a configuration property is defaulted conditionally based on the value of some other configuration property), then this is the place to do this.

The validate() method is called by the parent object to validate the values the user has passed in. This method may also be called directly by user code, should they wish to manually validate a configuration object. You should place any validation logic here related to your configuration property. If you need to "cross-validate" properties (validate the value of your property conditionally upon the value of another property), and the other property is on another builder object, increase the visibility of that other property field to "default", and reference it from this builder, by calling the getBuilder() method, which will gives you a handle on the root configuration builder.

The final step is to add parsing logic to the Parser class. First, add the attribute to name to the Attribute enum (this class simply provides a mapping between the non-type-safe name of the attribute in XML and a type-safe reference to use in the parser). Locate the relevant parseXXX() method on the class, and add a case to the switch statement for the attribute. Call the builder mutator you created above, performing any XML related validation (you are unlikely to need this), and type conversion (using the static methods on the primitive wrapper classes, String class, or relevant enum class).

Adding a group

In some situations you may additionally want to add a configuration grouping object, represented in XML as an element. You might want to do this if you are adding a new area of functionality to Infinispan. Identify the location of the new configuration grouping object. It might be added to the root Configuration object, or it might be added to one it's children, children's children. We'll call the parent YYY in the steps below.

Create the XXXConfiguration object. Add any properties required following the guide for adding properties. The constructors visibility should be "default".

Create the XXXConfigurationBuilder object. It should subclass the relevant configuration child builder -- use the YYYConfigurationChildBuilder as the superclass. This will ensure that all builder methods that allow the user to "escape" are provided correctly (i.e provide access to other grouping elements), and also require you to provide a create() and validate() method. The constructor needs to take the the YYYConfigurationBuilder as an argument, and pass this to the superclass (this simply allows access to the root of the builder tree using the getBuilder() method).

Follow the property adding guide to add any properties you need to the builder. The create() method needs to return a new instance of the XXXConfiguration object. Implement any validation needed in the validate() method.

In the YYYConfiguration object, add your new configuration class as a private final field, add an accessor, and add initialiser assignment in the constructor

In the YYYConfigurationBuilder, add your new configuration builder as a private final field, and initialise it in the constructor with a new instance. Finally, add an accessor for it following the standard pattern discussed in the guide.

In the YYYConfigurationBuilder ensure that your validate method is called in it's validate method, and that result of the XXXConfiguration instances' create method is passed to the constructor of YYYConfiguration

Finally, add this to the parser. First, add the element to the Element class, which provides a type safe representation of the element name in XML. In the Parser class, add a new parseXXX method, copying one of the others that most matches your requirements (parse methods either parse elements only - look for ParseUtils,requireNoAttributes(), attributes only -- look for ParseUtils.requireNoContent() or a combination of both -- look for an iterator over both elements and attributes). Add any attributes as discussed in the adding a property guide. Finally, wire this in by locating the parseYYY() method, and adding an element to the switch statement, that calls your new parseXXX() method.

Bridging to the old configuration

Until we entirely swap out the old configuration you will need to add your property to the old configuration (no need to worry about jaxb mappings though!), and then add some code to the LegacyConfigurationAdaptor to adapt both ways. It's fairly straightforward, just locate the relevant point in the adapt() method (near the configuration group you are using) and map from the legacy configuration to the new configuration, or vs versa. You will need to map both ways, in both adapt methods.

Startup performance

2011-12-22T08:41:00.000-08:00

One of the things I've done recently was to benchmark how quickly Infinispan starts up. Specifically looking at LOCAL mode (where you don't have the delays of opening sockets and discovery protocols you see in clustered mode), I wrote up a very simple test to start up 2000 caches in a loop, using the same cache manager.

This is a pretty valid use case, since when used as a non-clustered 2nd level cache in Hibernate, a separate cache instance is created per entity type, and in the past this has become somewhat of a bottleneck.

In this test, I compared Infinispan 5.0.1.Final, 5.1.0.CR1 and 5.1.0.CR2. 5.1.0 is significantly quicker, but I used this test (and subsequent profiling) to commit a couple of interesting changes in 5.1.0.CR2, which has improved things even more - both in terms of CPU performance as well as memory footprint.

Essentially, 5.1.0.CR1 made use of Jandex to perform annotation scanning of internal components at build-time, to prevent expensive reflection calls to determine component dependencies and lifecycle at runtime. 5.1.0.CR2 takes this concept a step further - now we don't just cache annotation lookups at build-time, but entire dependency graphs. And determining and ordering of lifecycle methods are done at build-time too, again making startup times significantly quicker while offering a much tighter memory footprint.

Enough talk. Here is the test used, and here are the performance numbers, as per my laptop, a 2010 MacBook Pro with an i5 CPU.

Multiverse:InfinispanStartupBenchmark manik [master]$ ./bench.sh
---- Starting benchmark ---

Please standby ...

Using Infinispan 5.0.1.FINAL (JMX enabled? false)
Created 2000 caches in 10.9 seconds and consumed 172.32 Mb of memory.

Using Infinispan 5.0.1.FINAL (JMX enabled? true)
Created 2000 caches in 56.18 seconds and consumed 315.21 Mb of memory.

Using Infinispan 5.1.0.CR1 (JMX enabled? false)
Created 2000 caches in 7.13 seconds and consumed 157.5 Mb of memory.

Using Infinispan 5.1.0.CR1 (JMX enabled? true)
Created 2000 caches in 34.9 seconds and consumed 243.33 Mb of memory.

Using Infinispan 5.1.0.CR2(JMX enabled? false)
Created 2000 caches in 3.18 seconds and consumed 142.2 Mb of memory.

Using Infinispan 5.1.0.CR2(JMX enabled? true)
Created 2000 caches in 17.62 seconds and consumed 176.13 Mb of memory.

A whopping 3.5 times faster, and significantly more memory-efficient especially when enabling JMX reporting. :-)

Enjoy!
Manik

Infinispan 5.1.0.CR2 is out in time for Xmas!

2011-12-21T02:05:00.000-08:00

Infinispan 'Brahma' 5.1.0.CR2 is out now with a load of fixes and a few internal changes such the move to a StaX based XML parser as opposed to relying on JAXB which did not get in for CR1. The new parser is a lot faster and has less overhead and does not require any changes from a user perspective.

We've also worked on improving startup time by indexing annotation metadata at build time and reading it at runtime. From a Infinispan user perspective, there's been some changes to how Infinispan is extended, in particular related to custom command implementations, where we know use JDK's ServiceLoader to load them.

As per usual, downloads are in the usual place, use the forums to provide feedback and report any issues.

Cheers, Merry Christmas and a Happy New Year to all the Infinispan community! :)
Galder

First Infinispan 5.1.0 'Brahma' candidate release is out!

2011-12-06T06:22:00.001-08:00

We're getting close to releasing Infinispan 5.1 'Brahma', and today I have the pleasure of announcing the Infinispan 5.1.0.CR1, our first release candidate. So, what's in it?

Ahead of future eventual consistency support, Infinispan now supports versioned cache entries which means that existing write skew checks on REPEATABLE_READ caches can be done more accurately.
Support for CDI injection of remote caches! Thanks to excellent work of community contributor Kevin Pollet, you can now inject remote caches as well as embedded caches using CDI. Detailed documentation on how to use is available here. In the mean time, checkout the CDI integration module in the Infinispan source code for examples.

Finally, we've introduced considerable new functionality in the previous Infinispan 5.1 alpha/beta releases, and so this first release candidate contains some important fixes for the newly introduced functionality, so if you're using any previous alpha/beta releases, please upgrade asap and provide us some feedback!

Cheers,

Galder

Infinispan coming to the French Alps!

2011-12-06T05:52:00.001-08:00

Remember that on the 15th of December, I'll be speaking at the Alpes JUG in Grenoble about Infinispan. This is a great opportunity for anyone interested in topics such as data caching and data grids to come and learn about Infinispan and its ecosystem, including Hibernate second level cache, Hibernate OGM...etc.

Looking forward to meeting Emannuel and the rest of the Alpes JUG gang :)

Cheers,
Galder

Infinispan @Devoxx

2011-11-25T09:39:00.000-08:00

Compared with the previous editions, this year's Devoxx was not that different: well organised, packed with interesting presentations and full rooms. And plenty of Belgian beer :)
Pete Muir, Sanne Grinovero and myself were also given the chance to speak. And we did take our time with a three hours deep dive into the Infinispan ecosystem, plenty of live demos and good discussions.
If you couldn't make it and you can't wait for the video to be published don't worry, the demo is available online here. Give it a spin and let us know what you think!

Cheers,
Mircea

More on transaction performance: use1PcForAutoCommitTransactions

2011-11-23T08:21:00.000-08:00

What's use1PcForAutoCommitTransactions all about?

Don't be scared the name, use1PcForAutoCommitTransactions is a new feature (5.1.CR1) that does quite a cool thing: increases your transactions's performance.
Let me explain.
Before Infinispan 5.1 you could access the cache both transactional and non-transactional. Naturally the non-transactional access is faster and offers less consistency guarantees.But we don't support mixed access in Infinispan 5.1, so what what's to be done when you need the speed of non-transactional access and you are ready to trade some consistency guarantees for it?
Well here is where use1PcForAutoCommitTransactions helps you. What is does is forces an induced (autoCommit=true) transaction to commit in a single phase. So only 1 RPC instead of 2RPCs as in the case of a full 2 Phase Commit (2PC).

At what cost?

You might end up with inconsistent data if multiple transactions modify the same key concurrently. But if you know that's not the case, or you can live with it then use1PcForAutoCommitTransactions will help your performance considerably.

An example

Let's say you do a simple put operation outside the scope of a transaction:

Now let's see how this would behave if the cache has several different transaction configurations:

Not using 1PC...

The put will happen in two RPCs/steps: a prepare message is sent around and then a commit.

Using 1PC...

The put happens in one RPC as the prepare and the commit are merged. Better performance.

Not using autoCommit

An exception is thrown, as this is a transactional cache and invocations must happen within the scope of a transaction.

Enjoy!
Mircea

Infinispan 5.1.0.BETA5 is out!

2011-11-22T00:46:00.001-08:00

Infinispan 5.1.0.BETA5 has just been the released with a few interesting additions and important fixes:

Locks acquired within a transaction are now reordered in order to avoid deadlocks. There's no new configuration required to take advantage of this feature. More information on how lock reordering works can be found here.
One of the aims of Infinispan 5.1 'Brahma' series is to move away from JAXB and instead use Stax based XML parsing. Ahead of that, a new configuration API based on builders has been developed. Expect to hear more about it and examples on using the API in the next few days.

Amongst the fixes included in this release, it's worth mentioning:

The demo paths that were broken in 5.1.0.BETA4 have now been fixed.
Some of the Infinispan jars in 5.1.0.BETA4 were showing duplicate classes. This was the result of an OSGI bundle generation bug, and so to avoid the issue 5.1.0.BETA5 OSGI bundle generation has been disabled. This functionality will be re-enabled once the issue has been fixed by the Maven Felix plugin.

As always, please keep the feedback coming. You can download the release from here and you get further details on the issues addressed in the changelog.

Cheers,

Galder

Some worth mentioning improvements for pessimistic transactions

2011-11-11T04:35:00.000-08:00

Pessimistic transactions were added in 5.1 and are the "rebranding" of eager transactions from previous Infinispan releases. But besides the re-branding, the code also brought some worth mentioning performance optimisation:

a single RPC happens for acquiring lock on a key, disregarding the number of invocations. So if you call cache.put(k,v) in a loop, within the scope of the same transaction, there is only one remote call to the owner of k.
if the key you want to lock/write maps to the local node then no remote locks are acquired. In other words there won't be any RPCs for writing to a key that maps locally. This can be very powerful used in conjunction with the KeyAffinityService, as it allows you to control the locality of you keys.
during the two phase commit (2PC), the prepare phase doesn't perform any RPCs: this optimisation is based on the fact locks are already acquired on each write. This means that then number of RPCs during transactions lifespan is reduced with 1.
for some writes to the cache (e..g cache.put(k,v)) two RPCs were performed: one to acquire the remote lock and one to fetch the previous value. The obvious optimisation in this case was to make a single RPC for both operations - which we do starting with 5.1.

Enjoy!

Mircea

Fewer deadlocks, higher throughput

2011-11-10T17:20:00.000-08:00

Here's the problem: first transaction (T1) writes to key a and b in this order. Second transaction (T2) writes to key b and a - again order is relevant. Now with some "right timing" T1 manages to acquire lock on a and T2 acquires lock on b. And then they wait one for the other to release locks so that they can progress. This is what is called a deadlock and is really bad for your system throughput - but I won't insist on this aspect, as I've mentioned it a lot in my previous posts.

What I want to talk about though is a way to solve this problem. Quit a simple way - just force an order on your transaction writes and you're guaranteed not to deadlock: if both T1 and T2 write to a then b (lexicographical order) there won't be any deadlock. Ever.

But there's a catch. It's not always possible to define this order, simply because you can't or because you don't know all your keys at the very beginning of the transaction.

Now here's the good news: Infinispan orders the keys touched in a transaction for you. And it even defines an order so that you won't have to do that. Actually you don't have to anything, not even enable this feature, as it is already enabled for you by default.

Does it sound too good to be true? That's because it's only partially true. That is lock reordering only works if you're using optimistic locking. For pessimistic locking you still have to do it the old way - order your locks (that's of course if you can).

Wanna know more about it? Read this.

Expect and enjoy this feature in our next release 5.1.0.BETA5.

Stay tunned!

Mircea

Single lock owner: an important step forward

2011-11-09T12:57:00.000-08:00

The single lock owner is a highly requested Infinispan improvement. The basic idea behind it is that, when writing to a key, locks are no longer acquired on all the nodes that own that key, but only on a single designated node (named "main owner").

How does it help me?

Short version: if you use transactions that concurrently write to the same keys, this improvement significantly increases your system' throughput.

Long version: If you're using Infinispan with transactions that modify the same key(s) concurrently then you can easily end up in a deadlock. A deadlock can also occur if two transaction modify the same key at the same time - which is both inefficient and counter-intuitive. Such a deadlock means that at one transaction(or both) eventually rollback but also the lock on the key is held for the duration of a lockAquistionTimout config option (defaults to 10 seconds). These deadlocks reduces the throughput significantly as transactions threads are held inactive during deadlock time. On top of that, other transactions that want to operate on that key are also delayed, potentially resulting in a cascade effect.

What's the added performance penalty?

The only encountered performance penalty is during cluster topology changes. At that point the cluster needs to perform some additional computation (no RPC involved) to fail-over the acquired locks from previous to new owners.
Another noticeable aspect is that locks are now being released asynchronously, after the transaction commits. This doesn't add any burden to the transaction duration, but it means that locks are being held slightly longer. That's not something to be concerned about if you're not using transactions that compete for same locks though.
We plan to benchmark this feature using Radargun benchmark tool - we'll report back!

Want to know more?

You can read the single lock owner design wiki or/and follow the JIRA JIRA discussions.

More locking improvements in Infinispan 5.1.0.BETA4

2011-11-09T09:57:00.000-08:00

The latest beta in the Infinispan 5.1 "Brahma" series is out. So, what's in Infinispan 5.1.0.BETA4? Here are the highlights:

A hugely important lock acquisition improvement has been implemented that results in locks being acquired in only a single node in the cluster. This means that deadlocks as a result of multiple nodes updating the same key are no longer possible. Concurrent updates on a single key will now be queued in the node that 'owns' that key. For more info, please check the design wiki and keep an eye on this blog because Mircea Markus, who's the author of this enhancement, will be explaining it in more detail very shortly. Please note that you don't need to make any configuration or code changes to take advantage of this improvement.

A bunch of classes and interfaces in the core/ module have been migrated to an api/ and commons/ module in order to reduce the size of the dependencies that the Hot Rod Java client had. As a result, there's been a change in the hierarchy of Cache and CacheContainer classes, with the introduction of BasicCache and BasicCacheContainer, which are parent classes of existing Cache and CacheContainer classes respectively. What's important is that Hot Rod clients must now code againts BasicCache and BasicCacheContainers rather than Cache and CacheContainer. So previous code that was written like this will no longer compile:
```
import org.infinispan.Cache;
import org.infinispan.manager.CacheContainer;
import org.infinispan.client.hotrod.RemoteCacheManager;
...
CacheContainer cacheContainer = new RemoteCacheManager();
Cache cache = cacheContainer.getCache();
```
Instead, if Hot Rod clients want to continue using interfaces higher up the hierarchy from the remote cache/container classes, they'll have to write:
```
import org.infinispan.BasicCache;
import org.infinispan.manager.BasicCacheContainer;
import org.infinispan.client.hotrod.RemoteCacheManager;
...
BasicCacheContainer cacheContainer = new RemoteCacheManager();
BasicCache cache = cacheContainer.getCache();
```
Previous code that interacted against the RemoteCache and RemoteCacheManager should work as it used to:
```
import org.infinispan.client.hotrod.RemoteCache;
import org.infinispan.client.hotrod.RemoteCacheManager;
...
RemoteCacheManager cacheContainer = new RemoteCacheManager();
RemoteCache cache = cacheContainer.getCache();
```
We apologise for any inconvenience caused, but we think that the Hot Rod clients will hugely benefit from this vastly reducing the number of dependencies they need.

Finally, a few words about the ZIP distribution file. In BETA4 we've added some cache store implementations that were missing from previous releases, such as the RemoteCacheStore that talks to Hot Rod servers, and we've added a brand new demo application that implements a near-caching pattern using JMS. Please be aware that this demo is just a simple prototype of how near caches could be built using Infinispan and HornetQ.

As always, please keep the feedback coming. You can download the release from here and you get further details on the issues addressed in the changelog.

Cheers,
Galder

Infinispan 5.1.0.BETA3 is out with Atomic Map and Hot Rod improvements

2011-10-27T07:18:00.000-07:00

I'm very proud to announce yet another beta release in the 5.1 'Brahma' series. This time is the turn of Infinispan 5.1.0.BETA3 which apart from containing many small fixes, it comes with two major improvements:

Fine-grained Atomic Maps

Atomic Maps are special constructs that users can use to bundle data into the value side of a key/value pair. What's special about them is that when the map changes, only the changes or deltas of that map are transfered, which makes Atomic Maps very efficient from a replication perspective when individual elements are modified.

Up until Infinispan 5.1.0.BETA2, the other interesting characteristic of these Atomic Maps was the fact that Atomic Map locking and isolation happened at the the level of the entire Atomic Map. So, if a single key/value pair in the Atomic Map was modified, the entire map was locked.

Starting with Infinispan 5.1.0.BETA3, thanks to Vladimir Blagojevic, Atomic Maps supporting fine-grained locking are available as well. What this means is that an Atomic Map's key/value pairs can be modified in parallel thanks to the ability to lock individual map entries as opposed to the entire map.

This will be particularly handy for heavy Atomic Map users such as JBoss Application Server 7 which uses Atomic Maps for maintaining HTTP sessions, and Hibernate OGM which decomposes entities into Atomic Maps.

Hot Rod server topology improvements

When we originally designed Hot Rod protocol version 1.0, we decided that whenever a distributed cache wanted to send information about the topology of the backend servers to the clients, we'd send the hash ids of each of these nodes. At the time, this seemed like a good idea, until virtual nodes were implemented...

With virtual nodes, each physical Hot Rod server can potentially represent tens, hundreds or even thousands of different virtual nodes. If we stuck with the original protocol, that would mean that we'd have to send each virtual node's hash id back to the client. So, for a cluster of 8 nodes, and 1000 virtual nodes, that'd be at least 80kb of hash ids being transfered back to the client, on top of tons of redundant information about a node's host and port, which is very inefficient.

So, after having some discussions, we decided to evolve the Hot Rod protocol to version 1.1 in order to address this issue. The end result is that now it's the responsibility of the Hot Rod client to generate the hash ids of each of the physical nodes. We do that by sticking to a general formula to generate a Hot Rod server's hash id which both the Hot Rod server and clients can implement.

This improvement has also lead to the significant decrease in memory consumption of the Hot Rod server because it does not need to cache those hash ids anymore.

So, if you are using Infinispan Hot Rod servers and in particular you'are configuring virtual nodes, you definitely should be upgrading your Hot Rod server and client libraries. From a client code perspective, no changes are necessary because starting with 5.1.0.BETA3, Hot Rod clients talk to servers using this latest protocol.

Finally, remember to use user forums to report back, grab the release here, enjoy and keep the feedback coming!!

Cheers,
Galder

Infinispan 5.1.0.BETA2 is out and asymmetric clusters are here!

2011-10-19T00:01:00.000-07:00

The latest beta of the 5.1 'Brahma' series, 5.1.0.BETA2, is out now and thanks to Dan Berindei, it comes with support for asymmetric clusters which has been highly demanded.

Before asymmetric clusters were supported, it was required that all Infinispan caches that client code interacted against were defined and running in all nodes in the cluster, otherwise, cluster wide messages for a cache that did not exist in a node would fail. So, imagine this scenario where c1 and c2 are user defined caches configured with replication:

Node A [c1]
Node B [c1, c2]

Without asymmetric clusters, whenever c2 cache was modified in Node B, a replication message would be sent to Node A, but the replication would fail indicating that c2 was not defined in Node A. This failure would get propagated back to Node B which would result in the modification failing. This kind of problems can particularly affect managed environments such as the JBoss Application Server, because often, deployments will be made in a subset of the cluster, so it could well happen that not all nodes have a particular cache started.

So, what Infinispan 5.1.0.BETA2 'Brahma' brings is support for this type of scenarios by maintaining a view correlating nodes and started caches, hence allowing any node to know which other nodes have a particular cache started. This means that in the above case, Node B would not have sent a replication message to Node A because it would know that c2 was only started in Node B.

The lack of support for asymmetric clusters is what forced Infinispan servers to only accept invocations for predefined caches because these predefined could be started when the servers were started, hence avoiding the asymmetric cluster problem. Now that asymmetric clusters are supported, it's likely that this limitation go away, but the timeline is to be defined yet.

This release also includes a bunch of other fixes and as always, please use the user forums to report back, grab the release here, enjoy and keep the feedback coming.

Cheers,
Galder