This section describes the phases of a deployment and the JMS messages that the DeploymentManager
sends to coordinate each phase across multiple deployment servers.
Start Deployment Phase
When a call to the deploy()
method of the DeploymentManager
is received, the DeploymentManager
sends a START_DEPLOYMENT
message. No deployment engine processing occurs at this point; the message exists principally to allow custom integration with the deployment system. (Note: if another deployment is in progress when the call to the deploy()
method is received, the second deployment is queued.)
A thread is then spawned that manages the rest of the deployment process. This thread is the main or management thread; there is only one instance, and it resides on the calling machine. After this thread is spawned, control is returned to the caller. Note that the DeploymentData
objects that are passed into the deploy()
method are retained by the management thread. They should not be altered by any client code.
Then, in the management thread, the DeploymentManager
begins the process of writing all the DeploymentData
and Markers
to the deployment repository. This process is controlled entirely by the DeploymentManager
to which the deploy()
call was made. To write the data efficiently to the deployment repository, the DeploymentManager
spawns no more than maxThreadCount
number of worker threads, assigning a number of DeploymentData
and Marker
objects to each thread, not to exceed threadBatchSize
. Only the number of threads that need to be spawned are started. Just before starting the worker threads, the DeploymentManager
sends a MARKER_PERSISTENCE
message.
Pre-Deployment Phase
Once the threadBatchSize
number of Marker objects have been written, the deployment enters a pre-deployment phase, during which, on a full deployment, all repository items are deleted from the target repositories. Depending on the configuration (specifically, when the /atg/deployment/file/DeploymentConfiguration.noVerificationByChecksum
option is enabled), all files may be deleted from the target VirtualFileSystems
in a similar manner.
When the pre-deployment phase is complete, the DeploymentManager
sends an ADD_UPDATE_PHASE
message that triggers the start of the phase in which data is actually deployed.
Add/Update Phase
The ADD_UPDATE_PHASE
message is sent to a deployment-specific JMS topic. The message contains the ID of the deployment associated with the message. Instances of the DeploymentManager
on each server are subscribed to that topic and begin processing on receipt of this message; this includes the DeploymentManager
component on the server that is managing the entire deployment process.
During the add/update phase, all items whose action property value is add
or update
are created. In addition, all properties with primitive types are set on items whose action is add
or update
. Any properties of repository items that are required references are set to a temporary dummy item. Only one dummy item of each referenced item descriptor is ever created; these are deleted at the end of the deployment. Any properties marked as deployable=false
are not deployed. Finally, the marker item status is set to ADD_UPDATE_COMMITTED
.
Concurrently with the repository item operations, any file whose action is add
or update
is copied to the responsible deployment agents.
If an error occurs, the current transaction is rolled back. In a separate transaction, the status for the marker that failed in the current batch is set to FAILURE
. The deployment’s failureCount
property is incremented, and the marker is removed from the worker thread’s list of items to operate on. The transaction is restarted from the beginning, skipping the item that failed. When the failureCount
is greater than the maxFailureCount
property configured in the DeploymentManager
, the entire deployment fails.
Once the management thread determines that all marker statuses are ADD_UPDATE_COMMITTED
, it begins the next phase of deployment.
Reference Resolution Phase
During this phase, all repository items with an action of add
or update
that contain references to other items, either a single reference or a collection of references, are resolved. To start this phase, the management thread sends a REFERENCE_UPDATE_PHASE
message to the deployment-specific JMS topic. As in the first phase, each DeploymentManager
starts all its threads and begins querying the deployment repository for work.
At the end of this phase, each marker that has been processed has its status changed to REFERENCES_COMMITTED
. Note that any Marker
whose action is delete
also has its status changed to REFERENCES_COMMITTED
.
For file assets, this deployment phase is ignored.
Delete Phase
This phase starts when the management thread sends a DELETE_PHASE
message. Processing for this phase is similar to the previous two. All worker threads are started, and each one requests a series of Markers
to process. In this phase, only Markers
whose action is delete
are processed. For those, the specified items are deleted from their repository. If an error occurs, the transaction is rolled back and all the Marker
statuses are set to FAILURE.
When all the deletions are complete, control returns to the management thread, which sets the deployment’s status field to DATA_DEPLOYMENT_COMPLETE
.
Destination Synchronization Phase
During this phase, all the destination repositories are synchronized by invalidating the caches for all the repositories on the target instances.
Note: For large file deployments in certain configurations (when the /atg/deployment/file/DeploymentConfiguration.noVerificationByChecksum
option is disabled, or on the second apply phase of a switched deployment when ATG Content Administration is being used), operations that occur on the target can be time consuming.
Completing the Deployment
Finally the management thread sets the status of the deployment to DEPLOYMENT_COMPLETE
and then sends a COMPLETE_DEPLOYMENT
message to all the DeploymentManager
components. If the purgeDeploymentData
flag is true in the deployment repository item, the Marker
and deploymentData
items are removed from the repository before the status is set.