Manik's take on JUDCon India

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

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

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:

• Optimistic vs pessimistic locking separation, single node locking and lock reordering
• Asymmetric cluster supports
• Fine-grained atomic maps

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

• Move to Stax XML parser and new programmatic configuration
• Hot Rod protocol 1.1 to provide better support for environments with virtual nodes enabled
• Startup performance
• Push-based state transfer for replicated caches

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

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!

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!

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

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">

to

<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

1. 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.


2. 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).


3. 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.


4. 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.


5. 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.

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


2. 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).


3. 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.


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


5. 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.


6. 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


7. 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.