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…)

Over the last few months, I’ve been talking to a lot of people, doing conference sessions about cloud computing and I’ve found out a lot about the different architectures in this space. I’m still very happy with our architecture (perhaps even happier) even after of all these discussions. In past blog posts and in our whitepaper, we’ve explained how the new Resin 4 cloud architecture works. Now I’ll talk a little about why it’s a nice alternative to other approaches.

(more…)

Last week I was been looking at ways to take advantage of Resin 4.0’s new cloud features within Amazon EC2. I’m in the process of developing some tools to make this simpler, but in the meantime, it’s already possible to get up and running with Resin 3.1 on Amazon EC2. In this post, I’ll show you how to create an Amazon Machine Image (AMI) with Resin and install WordPress on Quercus with MySQL so that your data persists on the Elastic Block Store.

(more…)

There’s a lot of talk about “Cloud Computing” right now, including from Caucho, but much of it seems vague or over-hyped. You hear more talk about benefits of scaling, redundancy, and cost savings than about actual features. We recently put out a whitepaper talking about Resin 4.0’s support for cloud that hopefully shows what we’re providing. However it is a pretty big document with quite a bit of behind the scenes technical detail, so I thought I’d break it down a bit here to give you a look at where we fit into the cloud environment. In other words, here are the actual features in Resin 4’s cloud support.

(more…)

Because the main purpose of Resin 4.0 was support for dynamic servers, we needed to upgrade our distributed session management to handle the case where servers can appear and disappear frequently. Resin 3.1 session replication relies on a static set of servers to choose backup and triplicate servers. Dynamic servers change that model because a 3.1 session backup might be shut down indefinitely. So we needed a new architecture.

At the same time as we redesigned sessions, I wanted to generalize the distributed store to support standard caching and storage using the javax.cache API, while retaining the scalability and reliability of our original design.

• A hub of 3 fully-redundant servers for reliability (the triad)
• Other servers dynamically appear and disappear for deployment flexibility
• Updates using lightweight messaging using BAM/HMTP
• Cache entry ownership and leasing for performance
• Support storage (infinite expire), caching (timed expire), and session (timed idle invalidation)
• Support serialized objects (using Hessian), and binary data

The cache architecture is heavily influenced by the messaging and extra complications of distribution.

(more…)

Every Friday, the Caucho engineers get together to discuss the work we’ve done over the past week and to plan for the next week and beyond. As an experiment, I’m going to start a new weekly series on this blog giving a summary of our meetings. We hope you enjoy it…

Starting with version 4.0, Resin is moving in a new direction to allow users to take advantage of cloud computing infrastructure more effectively. Of course one of the first problems with “cloud computing” is the name itself. It seems like everyone has a vague (perhaps cloudy?) notion of what cloud computing is, so I did a bit of research before Friday’s meeting to make sure that we weren’t adding yet another definition to the mix. Happily, it turns out that we’re not. While the actual implementation of cloud computing infrastructure and tooling is under construction, the desire to be able to run applications transparently on a dynamically changing set of servers seems to be constant.

Our notion of cloud computing is that numerous instances of Resin will be run within virtual machines on hardware that may or may not be managed by the user. The behavior of these Resin clusters will appear to the application to be the same as if they are running on a single instance. The only thing that changes is the ability to scale as the application is running both up and down. What’s new about our approach is that it introduces distributed sessions, caching, and application deployment for web applications.

One of the other topics that came up at our meeting was Quercus Personal. Whenever we go to tradeshows or talk about Quercus, inevitably people want to run the compiled version for personal or hobby projects, but the full professional version of Resin is a bit out of their price range or they don’t really need clustering features. To address this market, we’re planning Quercus Personal which is exactly like Resin Open Source, except that Quercus compilation is available to speed up PHP. The price point is much lower since enterprise clustering is not included. Our goal is to make this version of Quercus just as easy as installing a LAMP stack or nginx/PHP.

Finally we talked about my work on the Eclipse plugin for Resin. This plugin is based on the Eclipse Webtools generic server functionality. We’ve got a basic version working with the standard .war deployment, but I recently made some modifications to allow running a web app directly from the Eclipse project directory. Resin 4.0 now allows deploying a web app dynamically across the cluster, so we also added a way to access that functionality directly from Eclipse. There are still a few places where we need to add UI elements to make this more natural within the Webtools framework, but the basic operation is now available. Of course, we’ll also be documenting the plugin and making it available for installation from directly within Eclipse.