Nav

Application Deployment

Starting Mule

Start mule by running <MULE_HOME>/bin/mule or starting Mule as a service. By default, applications in the <MULE_HOME>/apps directory will be deployed. You can also designate specific applications to start (separated by the colon - :) and Mule 3.0 will respect the order when starting the applications. In this scenario, only the applications specified will be started.

Start Mule by specifying an app to run:


         
      
1
mule -app foo

where foo is a Mule app at $MULE_HOME/apps/foo.

From this moment, Mule checks every three seconds for the $MULE_HOME/apps/foo/mule-config.xml updates. One can update the application jar contents and touch/modify this file to have Mule reload the config and class modifications.

Deploying Applications

Mule applications, either zipped or exploded can be dropped into $MULE_HOME/apps. If Mule is already running, the application will be deployed dynamically.

All applications in Mule are unpacked at runtime and original zip removed. This means, e.g. that dropping a zip file into 'apps' dir will create a new folder with the same name (sans 'zip' extension) and delete the zip.

A successful app deployment is confirmed by:

  • Having an unpacked application folder in the apps dir. E.g. for stockTrader.zip- $MULE_HOME/apps/stockTrader.

  • An anchor file created for a running app, e.g. $MULE_HOME/apps/stockTrader-anchor.txt

If you wish to store your applications in a different location, you can do this on Unix-based systems by creating a symlink to your application directory from $MULE_HOME/apps.

Deploying Applications in Parallel

In Mule 3.8.2 and later, you can deploy applications in parallel. Deploying applications in parallel reduces the startup time when you deploy a large number. The maximum number of deployment threads is set to 20 and is not configurable. To prevent deployment failure, ensure that applications are not dependent on each other because a particular start order cannot be guaranteed.

To enable parallel deployment, start Mule using the -M-Dmule.deployment.parallel option. For example:

mule -M-Dmule.deployment.parallel

All applications in the /apps directory start in parallel.

Undeploying Applications

It is recommended one doesn’t delete the application folder directly, but rather an app’s anchor file only:

  1. Prevents any interference from the hot-deployment layer and doesn’t leave room for concurrent conflicting actions.

  2. Avoids potential application jar locking issues on some operation systems and allows for clean shutdown and undeployment.

E.g. if the stockTrader app is running (app folder is there as well as the $MULE_HOME/apps/stockTrader-anchor.txt file, just delete the anchor file to have the app removed from the Mule instance at runtime. Application folder will be removed once the app terminates.

Updating Applications at Runtime

Updating a Mule application at runtime can be a complex change involving class modifications, endpoint modifications (e.g. changing ports, etc), as well as reconfigured flows. As a result, any application update does a graceful app shutdown under the hood and reconfigures itself. In practice, this is pretty transparent to the user and happens within seconds.

There are several ways an application can be updated:

  • By dropping the modifications over an existing exploded app folder and touching the 'master' configuration file (mule-config.xml in app root by default).

  • By dropping a new zipped version of the app into $MULE_HOME/apps dir. Mule will detect this as an existing app update and will ensure a clean redeployment of the app. Note that any modifications to the old app folder are discarded - the new app folder is a clean exploded application from a zip.

As you see, both integrate pretty well with existing build tools, the preference for one over another really depends on established development practices only.

Sharing Resources

If you’re deploying multiple applications to the same place and those applications could share the same resources, then you can create a common domain where you can define common configurations that can then be referenced by multiple projects. This allows you to, for example, expose different services in different projects through the same HTTP host and port and be able to deploy everything without any conflicts. Read More.

Disabling the Mule Container Mode

If you want to run Mule 3 the legacy 2.x way, edit $MULE_HOME/conf/wrapper.conf file and replace the following line:


         
      
1
2
# Java Main class
wrapper.java.mainclass=org.mule.module.reboot.MuleContainerBootstrap

with this one:


         
      
1
2
# Java Main class
wrapper.java.mainclass=org.mule.module.boot.MuleBootstrap

When run in this legacy mode, none of the new application deployment features apply

Embedded Mule

When Mule is embedded in an application server, Java application, unit test, IDE, etc and started programmatically, the deployment functionality is disabled and Mule follows the legacy application model.

Troubleshooting

If application fails to start (e.g. broken configuration file provided), Mule will not monitor the app for changes (as there technically is no application running). To update such an app, simply redeploy the app by dropping an updated archive into the apps folder.