jbonofre's blog

Introduction One of the first purpose of Apache Karaf Cellar is to synchronize the state of each Karaf instances in the Cellar cluster. It means that any change performed on one node (install a feature, start a bundle, add a config, etc) generates a “cluster event” which is broadcasted by Cellar to all others nodes. The target node handles the “cluster event” and performed the corresponding action (install a feature, start a bundle, add a config, etc). By default, the nodes have the same role. It means that you can perform actions on any node. But, you may prefer to have one node dedicated to the management. It’s what we name “central management”. Central management With central management, one node is identified by the manager. It means that cluster actions will be performed only on this node. The manager is the only one which is able to produce cluster event. The managed nodes are only able to receive and handle events, not to produce. With th...

Apache Karaf Cellar 2.2.3 Around one week ago, we released Karaf Cellar 2.2.3. In addition of the first Distributed OSGi support (DOSGi, I already wrote blog ), an interesting feature of Cellar 2.2.3 is to give access the whole Hazelcast configuration. The etc/hazelcast.xml is the core configuration of the Hazelcast instance, started by the Cellar feature. Cellar registers the Hazelcast instance as an OSGi service. It means that we can use the Hazelcast instance just using a reference to the corresponding OSGi service. We are going to use the Hazelcast OSGi service in a Camel route defined using blueprint DSL (it works using Spring DSL as well). Apache Camel 2.9.0 and the Hazelcast component Camel 2.9.0 provides a new component: camel-hazelcast. This component allows to send (as a producer/to) or receive (as a consumer/from) a Camel exchange through a Hazelcast distributed queue. The first route timerToQueue fires a message every 5 seconds, and send to a Hazelcast distributed queue. ...