Apache Karaf Cellar 2.2.5 released !

During the ApacheCon EU, I made a demo of Karaf and Cellar all together. During this demo, I used Cellar 2.2.5-SNAPSHOT.

Now, Cellar 2.2.5 is released ! But, what’s new in this version ?

Groups are now persistent

In Cellar 2.2.4, the empty groups disappear after a restart.

You created a new cluster group without any member (empty group) with:


karaf@root> cluster:group-create foobar
karaf@root> cluster:group-list|grep -i foobar
foobar []


If you restart Cellar (or Karaf), the empty groups were lost:


karaf@root> cluster:group-list|grep -i foobar


To avoid this, in Cellar 2.2.5, the cluster groups are now persistent on each node. We introduced a new groups property in etc/org.apache.karaf.cellar.groups.cfg to store the list of groups. Cellar now reads this property as startup to populate the cluster groups not present on the cluster.

On the other hand, the groups property in etc/org.apache.karaf.cellar.node.cfg defines the group membership of the local node.

If you restart Karaf (or Cellar), this group disappeared from

Cluster producers, consumers, and handlers persistency

Like for groups, with Cellar 2.2.4, the status of cluster event producers, consumers and handlers was not persistent. It means that if you stop the cluster event producer, for instance, after a restart, the producer was start again. So we loosed the status before the restart.

In Cellar 2.2.5, to avoid that, the status of cluster event producers, consumers and handlers is now persistent in etc/org.apache.karaf.cellar.node.cfg (it’s the current status on the local node). Cellar now reads the properties from this file at startup to set the previous status (before the restart).

Bundles blacklist and whitelist

In Cellar 2.2.4, the bundles blacklist and whitelist were not correct by default in etc/org.apache.karaf.cellar.groups.cfg: all bundles were blocked (inbound and outbound). If you tried to install a bundle on the cluster, you saw a “Bundle xxxx is BLOCKED …” in the log.

We changed the default setup to allow all bundle cluster events.

Config sync enhancement

In Cellar 2.2.4, to avoid infinite loop, we introduced a karaf.cellar.sync property appended to all synchronized configuration PID. This property contained the timestamp of the last Cellar configuration synchronization. This mechanism has two issues:

• it pollutes the configuration PID (it can be confusing for the users to see a “not usable” property)
• if a configuration change occurs between the timestamp and the Cellar configuration timeout, it’s not synchronized on the cluster

We changed the configuration synchronization mechanism in Cellar 2.2.5. The karaf.cellar.sync property has been removed. Now we compare the dictionary of configuration PID in the cluster (distributed map) and the local.

Bundle state, name, and symbolic name

The bundle distributed map stored only the bundle name. It was a little bit restrictive.

In Cellar 2.2.5, both bundle name and symbolic name are stored in the cluster distributed map.

It allows the users to select a bundle (on the cluster) using both name and symbolic name.

Improvements on the cluster:* commands and MBeans

In order to mimic the Karaf core commands and MBeans, the Cellar commands and MBeans have been improved.

The cluster:feature-install (and the corresponding MBeans) now supports norefresh and noclean options, as supported by features:install Karaf command.

The cluster:bundle-list supports the -l option (to display the bundle location) and -s option (to display the bundle symbolic name), as the bundles:list/osgi:list Karaf command.

The cluster:config-list command now allows to display directly a configuration PID dictionary.

A new command has been introduced in Cellar 2.2.5: cluster:sync. This command forces a synchronization on the local node. It’s particulary interesting when the node loosed the communication with the other nodes (for instance, due to a network issue), the cluster:sync forces the resynchronization of the node and the cluster (in both direction).

Restart issues

Cellar uses a LocalBundleListener to listen for changes on the local bundles, and broadcast these changes as a bundle cluster event.

In Cellar 2.2.4, this listener was a simple BundleListener. The problem was that this listener get the “bundle stop” local event when stopping the framework and broadcast it to the cluster (including to the local node). It means that the “latest” state on the bundle was “stopped”. At restart, the OSGi framework reset the bundle in “stopped” status (instead of “started”).

In Cellar 2.2.5, the listener has been changed to a SynchronousBundleListener. Thanks to this listener, we are able to get the stopping event from the OSGi framework. When the framework stops, Cellar disable the bundle listener in order to avoid to change the bundle states.

Like this, we restart the bundle in the correct state.

We hope that you will like this new Cellar 2.2.5 release. We mostly focused on the bug fixes to provide a more stable cluster solution for Karaf.

Now, we are preparing Cellar 2.2.6 with new bug fixes, new feature, etc. In the mean time, Cellar 2.3.0 is in preparation, supporting Karaf 2.3.x and new Hazelcast version.