Container-level locking allows bundles to be preloaded into the slave kernel instance in order to provide faster failover performance. Container-level locking is supported in both the simple file and JDBC locking mechanisms.
To implement container-level locking, add the following to the
etc/system.properties file on each system in the master/slave
setup:
Example 31. Container-level Locking Configuration
karaf.lock=true karaf.lock.level=50 karaf.lock.delay=10
The karaf.lock.level property tells the Fuse ESB Enterprise instance how far up the boot process to bring the OSGi container. Bundles assigned the same start level or lower will then also be started in that Fuse ESB Enterprise instance.
Bundle start levels are specified in etc/startup.properties, in the
format BundleName.jar=level. The core system
bundles have levels below 50, where as user bundles have levels greater than 50.
Table 6. Bundle Start Levels
| Start Level | Behavior |
|---|---|
| 1 | A 'cold' standby instance. Core bundles are not loaded into container. Slaves will wait until lock acquired to start server. |
| <50 | A 'hot' standby instance. Core bundles are loaded into the container. Slaves will wait until lock acquired to start user level bundles. The console will be accessible for each slave instance at this level. |
| >50 | This setting is not recommended as user bundles will be started. |
When using a 'hot' spare on the same host you need to set the JMX remote port to a
unique value to avoid bind conflicts. You can edit the servicemix start
script (or the karaf script on a child instance) to include the
following:
DEFAULT_JAVA_OPTS="-server $DEFAULT_JAVA_OPTS -Dcom.sun.management.jmxremote.port=1100 -Dcom.sun.management.jmxremote.authenticate=false"
 |  |  |
 |
