Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

anchortoptop

6.7. Configuring Failover Deployments

...

To use this feature, edit the $KARAF_HOME/etc/system.properties file as follows on each system in the master/slave setup:

...

Note: Ensure that the karaf.lock.dir property points to the same directory for both the master and slave instance, so that the slave can only acquire the lock when the master releases it.

...

  • Update the classpath to include the JDBC driver
  • Update the $KARAF_HOME/bin/karaf script to have unique JMX remote port set if instances reside on the same host
  • Update the $KARAF_HOME/etc/system.properties file as follows:

...

Note:

  • Will fail if JDBC driver is not on classpath.
  • The database name "sample" will be created if it does not exist on the database.
  • The first Karaf instance to acquire the locking table is the master instance.
  • If the connection to the database is lost, the master instance tries to gracefully shutdown, allowing a slave instance to become master when the database service is restored. The former master will require manual restart.

...

Otherwise, configure the system.properties file as normal for your setup, for example:

...

...

As with the default JDBC locking setup, the Oracle JDBC driver JAR file must be in your classpath. You can ensure this by copying the ojdbc14.jar into Karaf's lib folder before starting Karaf.

Note: The karaf.lock.jdbc.url requires an active SID, which means you must manually create a database instance before using this particular lock.anchor

locklevellocklevel

Container-level locking

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 $KARAF_HOME/etc/system.properties file on each system in the master/slave setup:

...

The karaf.log.level property tells the Karaf 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 Karaf instance.

...

Note: 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 Karaf start script to include the following:

...

#top

...