Considerations for Hot Deployment of Packages

Before you configure or preform hot deployment, keep the following behavior, limitations, and considerations in mind:

When enabled, Integration Server performs hot deployment for the installation of any custom package regardless of whether it is a new package or an upgraded package.

You can perform hot deployment for the entire package only. You cannot perform hot deployment for specific assets in a package. During hot deployment, Integration Server upgrades all the assets in a package.

To perform hot deployment of packages, you do not have to quiesce or restart Integration Server nodes.

Integration Server ensures that processes such as HTTP/HTTPS/FTP/FTPS requests, scheduler tasks, file polling requests, emails, Messaging/JMS requests, and web service requests continue while performing hot deployment of packages. During deployment, there might be a delay in response from those assets that are affected by the hot deployment of packages because Integration Server blocks the execution of assets that belong to or have dependency on the packages that are being deployed.

For example, during hot deployment, when Integration Server unloads the existing package information from memory, Integration Server disables the ports associated with the deployed packages. These ports will be enabled when the packages are activated successfully. Therefore, if you are hot deploying a package that has a port associated with it, access to services or other resources through those ports will fail until the port is successfully enabled.

To avoid the situation where a port in the package undergoing hot deployment is disabled, assign ports to packages that are not deployed using hot deployment.

Note:
When you create a port, you assign the port to a package. Integration Server stores the listener configuration information for the port in the package that you specify. Enabling or disabling the package that contains a port, enables or disables the port as well.

If any of the assets in the package being deployed or in dependent packages are currently being processed at the time of deployment, Integration Server waits for the processing to complete or waits a specified timeout period, whichever is earlier, before attempting to deploy the package. If the tasks are not done within the specified timeout period, the hot deployment might fail. To help ensure that hot deployment is successful, you must configure the hot deployment timeout value to a value that is greater than the time taken for the task to complete.

With regards to scheduled user tasks, Integration Server assesses the dependency of packages that are being deployed and permits the completion of any scheduled user tasks that are already running. Until hot deployment completes, Integration Server suspends any scheduled user tasks that have not yet started.

Hot deployment is not cluster aware. Hot deployment of packages may not happen at the same time on all the server nodes in a cluster. Also, info and debug messages related to hot deployment in one server node will not be shared across the cluster nodes.

In case the deployment of a new version of package fails, Integration Server provides the auto recover configuration option that you can use to instruct Integration Server to recover the earlier version of the package automatically.

Note:
When you install a package for the first time in Integration Server, if there is any error in hot deployment, Integration Server will not be able to automatically recover the package because a working copy of the package does not exist.

You can use the pub.packages.hotdeployment:cancel service to cancel a hot deployment operation. For more information, see webMethods Integration Server Built-In Services Reference .