Introduction to Deployment Synchronizer

A product's repository typically contains user-uploaded service archives, modules, service metadata, scheduled tasks etc. These artifacts are typically shared across multiples nodes in a cluster. Therefore, i n a clustered environment, the artifact repository (in WSO2 products, by default, it is <product-home>/repository/deployment/server) should be in sync between all the cluster nodes, in order to maintain consistency. Deployment Synchronizer allows you to synchronize these deployment artifacts across the nodes of a product cluster.

This synchronization functionality is provided by the following feature in the WSO2 feature repository:

Name: WSO2 Carbon - Deployment Synchronizer Feature
Identifier: org.wso2.carbon.deployment.synchronizer.feature.group 

  If Deployment Synchronizer is not included in your product by default, you can add it by installing the above feature using the instructions in Installing Features.  

Deployment Synchronizer has the following use cases:

• Maintaining an up-to-date backup of the artifact repository.
• Sharing a single artifact repository among multiple servers in a cluster.
  
• Enforcing artifact updates to be deployed on a server at runtime.

Currently, the WSO2 Deployment Synchronizer (DepSync) uses an SVN-based repository for storing shared deployment artifacts. The Subversion repository is used to sync the contents in the sync directory (the axis2 repo directory, <PRODUCT_HOME>/repository/deployment/server, by default). This method is efficient and high-performant. The synchronization process is as follows:

• When changes to the contents of axis2 repo directory are present, the Read-Write nodes commit those to the Subversion repository.
• Then, this node sends a cluster message to all other (slave) nodes specifying the repo is updated.
• When the slave nodes receive the message, they update their axis2 repo directory with what's in the svn repository.

Ghost deployment for better performance

From the DepSync feature which is based on Carbon 4.0.2 onwards, performance of the initial tenant loading time has been significantly improved. The improvements have been enabled by loading ghost artifacts instead of checking out the entire SVN repository at the time a tenant loads. When a tenan loads, DepSync typically updates all artifacts under its SVN repository. When the number of artifacts in a repo gradually increase, the initial tenant loading time gets higher. To improve the initial tenant loading time and avoid long delays and timeouts, new DepSync is optimized to checkout only the repo with depth=empty. For example,

svn co https://svn.wso2.org/repos/wso2/scratch/carbon-server-framework/--depth=empty

Next the ghost meta files of the actual artifacts are loaded to the repository. These ghost artifacts are lightweight XML files stored in <CARBON_HOME>\repository\deployment\server, with metadata references to the actual artifacts. Loading the ghostified formats of the actual artifacts is faster, more efficient and prevents first-request timeouts and delays. At the time a request is made for an actual artifact, the GhostDisptcher issues a DepSync update of the required artifacts only.

For example, if a request is made for a service, GhostDisptcher intercepts this request and then does the update of that service file only using following operations.

svn update axis2services --depth=empty
svn update axis2services/Version.aar

It resumes serving the request after deploying this service. The same scenario for a webapp request is handled by the GhostWebappDeployerValve.

With the ghost deployment model, there are significant performance improvements observed in the initial response times.

For instructions on configuring the SVN-based Deployment Synchronizer, see Configuring the SVN-Based Deployment Synchronizer .