Resin Documentation

packaging/deployment

Resin provides a wide variety of custom packaging and deployment options.

• web-app tags defines all of the available tags for web-app configuration.
• host tags defines all of the available tags for host configuration.

In this scenario, you want to configure a web-app with a specific root-directory and specify the location of the .war file. As usual, when Resin sees any changes in the .war file, it will expand the new data into the root-directory and restart the web-app. This capability, gives sites more flexibility where their directories and archive files should be placed, beyond the standard webapps directory.

The optional archive-path argument of the <web-app> will point to the .war file to be expanded.

<resin xmlns="http://caucho.com/ns/resin">
<cluster id="">
  <host id="">

    <web-app id="/foo" root-directory="/var/www/foo"
             archive-path="/usr/local/stage/foo.war"/>

  </host>
</cluster>
</resin>

Resin can deploy multiple versions of a web-app simultaneously, simplifying any application upgrades. The old version of the web-app will continue to receive old sessions, while the new version will get the new requests. So any user will see a consistent version as the web site update occurs with no downtime required.

The versioning requires <web-app-deploy>, i.e. it works with the webapps directory. The versioning is numerically-based, allowing dotted notation, to determine the most recent version. A simple deployment process might use foo-101 to upgrade from foo-100. A more complicated one might use foo-10.3.14 to upgrade from foo-10.3.13.

The versioning attribute of the <web-app-deploy> enables versioning:

<resin xmlns="http://caucho.com/ns/resin">
<cluster id="">
<host id="">

  <web-app-deploy path="webapps" versioning="true"/>

</host>
</cluster>
</resin>

It may be possible to deploy a web application to a live server without interruption to service if certain conditions are met.

1. The session objects for your users are being persisted.
2. The usage of session scoped objects between the old version and the new is compatible.
3. The usage of application scoped objects between the old version and the new is compatible.
4. Database schema changes are not required.

Resin allows you to have a backup instance running. The idea is that this backup instance of Resin takes over if your primary Resin instance goes down.

If you are using a load balancer to distribute your load to multiple primary servers, each primary server has a backup server.

You can use this feature to deploy to a live server without interruption of service.

1. shutdown primary server(s) (backup server(s) takes over)
2. deploy new war to primary server(s)
3. start primary server(s). As soon as the primary server starts, the user will be using the new version of the application.
4. deploy new war to backup server(s)

See JSP/Compilation.