In this post I’d like to provide a complete listing of all commands available in Resin. First, let’s enable resin:ManagerService. Open your resin.xml file and add <resin:ManagerService/> into <cluster-default> section. If you running Resin-Pro look for <resin:AdminServices/> tag and uncomment it. Remember that <cluster-default> applies settings to all configured clusters, e.g. app-tier and web-tier. (more…)

As I was working on the Resin’s NetBeans plug-in I started to realize that we needed to change the model we use for plugins. Previously, we packaged Resin’s classes with the plugins. That presented us with number of challenges ranging from keeping the plugins in sync with the Resin’s code to having to release the plugins every time we release a new version of Resin.

The solution was in introducing a level of indirection that came in the form an updated Resin CLI interface. Initially, the interface is extended with the commands required for the plugin to work. That included the deployment commands and web-application administration commands.
(more…)

Like other lightweight servlet containers and Java EE application servers, Resin’s deployment is file-system based. In order to deploy an application, all you need to do is copy your file to the Resin deployment directory. As you might also know, Resin has supported hot deployment for quite a while, which is a great feature for agile development that often results in frequent incremental deployments.

This deployment model is very simple, effective and popular. However, file-system based deployment has a few weaknesses that can arise in environments with very stringent availability and reliability requirements. It is very difficult to do deployment in a clustered environment because the same file must be deployed simultaneously to all servers in the cluster. Often this can result in some down-time that must be announced beforehand. No back-up facility is provided by the file system, so you must often save a backup copy of the old deployment somewhere yourself. File system based deployment also makes it very difficult to use the same server environment for different stages of development such as QA, user acceptance testing and production without following complicated deployment procedures.

The remote deployment model introduced in Resin 4.0 goes a long way in solving these particular problems by supporting clustered, versioned and staged deployment. This blog entry discusses these features in detail.
(more…)

We’ve been quiet on the blog for a while, but pretty busy behind the scenes for the last couple of weeks. There’s lots going on, but what I’m working on specifically is a new deployment model for Resin 4. In addition to our current file system based hot-deploy, we’re now adding a deploy model based on Git. We introduced this in Resin 4.0.0 and 4.0.1, but we started exploring the benefits of Git repositories and realized that we have the ability to do some really powerful things like sophisticated application versioning and rolling out applications in stages. I’ll show you the new model and give a preview of how you can use it in upcoming versions of Resin.

(more…)

For the Resin 4.0 remote deployment, I wanted some key features: incremental updates, transactional updates, reliable replication, manageability, and solid performance. It’s taken several months of toying with alternate architectures until the current design came together. At the core of the deployment architecture is the .git source code repository.

• atomic updates
• consistent file store - no broken updates
• independent - multiple writers and readers avoid seeing partial updates
• durable store to the filesystem (and replicated)
• incremental updates only of changed files

The key insight in the .git design is using a hash to identify versioned files. The hash design solves the transactional problem by treating files as immortal, immutable, written-in-stone documents.

(more…)

When you deploy an application using eclipse or ant, Resin propagates the .war updates to the cluster using the triad as the reliable store. The deployment is both incremental and transactional. Only changed files need to be sent, and the updates are only visible when they are complete and visible. Partial or incomplete deployment does not update the site.

1. eclipse/ant sends the .war to triad server A
2. Triad server A replicates the .war to triad servers B and C
3. The triad updates the rest of the cluster with the new .war file
4. Once all servers have the new version complete and verified, they can restart the web-app with the new data

(more…)