At a glance

First, it is important to understand what "replication" means and why it exists. Basically by replication we mean writing some data managed by sipXconfig (kept in the database) to a medium and at a location accessible by some entity. For instance grabbing a list of users with some of their properties from the database and writing them to an XML file to be used by the Imbot service. Or configuring some parameters of a service and writing them to an XML or properties service configuration file at a location accessible by the service. If necessary, a restart of the service can be triggered so that the new configuration to take effect.

While not complete, this article should give you a head start in understanding sipXconfig's replication mechanism.

Replication of service configurations

All configuration for each sipXecs service is created by sipXconfig and replicated to the system where the service runs through sipXsupervisor.

Replication of service configurations

In sipXconfig, the managed services configurations are kept in the database for presentation purposes. Each service keeps its configuration in xml XML files found at specific locations. A client may alter a service configuration via sipXconfig's UI or REST services. Obviously the configuration of each service must be kept in synch with sipXconfig's database. Thus a configuration change in sipXconfig will trigger a replication of the service's configuration. In particular cases, a service restart must be triggered in order for the new configuration to take effect.

Replications are triggered in 2 two ways: in bulk, via one of the ServiceConfigurator.replicateServiceConfig() overloaded methods or manually with the help of org.sipfoundry.sipxconfig.admin.commserver.SipxReplicationContext. In the first case all the configuration files of the service are replicated, in the second we can trigger specific file replciationreplications are triggered. Ideally all configurations files should be declared as configuration files that belong to a service and get replicated by the ServiceConfigurator, but there are cases when a single replication is performed.

Datasets replications

In addition to service configurations there is another type of replications: replication of datasets. TBD

...

In sipXconfig, services are configured registered as Spring beans in service.beans.xml. Here, amongst other properties, a list of "service configurations" is kept for each service.

...

org.sipfoundry.sipxconfig.admin.commserver.LazySipxReplicationContextImpl is the implementation of the SipxReplicationContext that takes care of the lazy replications. Replication jobs are kept in an ArrayList of ReplicationTasks. A worker thread sleeps while waiting for something to be done and when there is, it is notified, sleeps for a bit and then it triggers the queued replications.

In sipXconfig all the vast majority of replications are lazy, except dial planswith a few exceptions (dial plans, certificates, the deploy of conference bridges on some application events like the deletion of conferences).

Writing XML files

All configuration files extend the abstract class org.sipfoundry.sipxconfig.admin.AbstractConfigurationFile. org.sipfoundry.sipxconfig.admin.TemplateConfigurationFile is a Common base class for all configuration files generators that use Velocity templating engine.

...

Other types of configuration files can be viewed by checking out the type hierarchy of org.sipfoundry.sipxconfig.admin.AbstractConfigurationFile.

isReplicable(Location location) and isRestartRequired()

The two are methods of the org.sipfoundry.sipxconfig.admin.ConfigurationFile interface.
From the javadoc, the method isReplicable(Location location) verifies if this configuration file can be replicated on the given location. The isRestartRequired() method checks if a service need to be restarted when this configuration file is changed.

isReplicable(Location location) is implemented in the abstract class AbstractConfigurationFile. It will return always true. Implementations of the AbstractConfigurationFile must override this method in order to provide aditional checks to make sure the file is replicable at requested location. For instance one might want to see if the service is installed at the specific location in order to replicate its configuration there.

isRestartRequired() is initialized with true in AbstractConfigurationFile. Its value can be overridden by implementing the method in configuration or by setting the configuration bean property restartRequired.

  <bean id="presenceRoutingConfiguration" class="org.sipfoundry.sipxconfig.service.PresenceRoutingConfiguration"
    parent="defaultConfigurationFile">
    <property name="name" value="presencerouting-prefs.xml"/>
    <property name="coreContext" ref="coreContext" />
    <property name="restartRequired" value="false" />
  </bean>

Replication triggers

Short info. See Replication triggers

...