This tutorial is going to cover the basics of using Resin with Amazon Web Services for cloud deployment. If you are new to cloud computing and IaaS, follow along and you will soon be deploying Java web applications in the cloud. You wil create an EC2 instance. You will download and install Resin on Ubuntu on a local machine. You will install Resin on an Amazon Linux AMI instance (EC2 instance). You will use Roo to create a simple application and deploy it.

We use Roo because Spring is fairly widely used, and Roo is a quick way to generate a sample app. Future tutorials will use other common Java tools as well as show you how to configure and manage a complete Resin cluster. Think of this as the first tutorial in a series of tutorials.

For this tutorial you will need Resin 4.0.24 or later. Check back periodically because as we are going to expand the tutorial and improve Resin’s support of cloud deployments. The Resin engineering team plans on improving cloud support continuously.

Many of the steps in this tutorial would be similar even if you were using Eucalyptus, CloudStack with CloudBridge, RightScale myCloud, OpenNebula, or OpenStack, this guide should help you along as they all support the Amazon EC2 REST APIs. Also any cloud computing environment (private or public, on premises or hosted) will have similar characteristics. Thus even if you are using a private cloud using OpenStack like Project Olympus, the principles will be the same. In fact even using remote servers deployed in a datacenter or virtualized servers with Xen Server, Xen Cloud orVMWare vSphere the steps will be very similar.

For this tutorial we expect you are familiar with starting, and stoping Amazon WS instances. If you are not, go through this tutorial from Amazon WS. You will need an Amazon WS account. Amazon WS allows you to have free tier so you can learn Amazon WS (EC2, S3, Elastic Load Balancer, Block Storage, SimpleDB, Simple Queue Service, Simple Notification Service).

The second tutorial in this series will use Euca2ools to start and stop VM instances from the command line.

(more…)

Configuration variable substitution using <resin:properties> and rvar()

This first part of a multi-part article on Resin configuration examines how to use EL variables in various situations to simplify Resin configuration. When we’re done you’ll understand how a simple database resource like this:

  <database jndi-name="jdbc/mysql">
    <driver type="com.mysql.jdbc.Driver">
      <url>jdbc:mysql://user:password@$192.168.1.1:3306/dbname</url>
    </driver>
  </database>

… can be dynamically merged with per-server properties like this:

dbserver : 192.168.1.1
app-0.dbserver : 192.168.1.23
app-1.dbserver : 192.168.1.64

… resulting in configuration that is simple, powerful, and well suited for deployment in a cloud environment.

Read the rest of this entry on the Caucho Wiki »

Memcached is a widely used distributed caching system employed by some of the world’s largest websites. Resin’s new Memcached transport enables access to our powerful distributed cache at the wire protocol layer! This means Resin can function as a drop-in replacement for Memcached solutions. Resin’s Memcached support is durable and fully elastic, allowing for the addition or removal of nodes as needed.

The big advantage Resin cache has over Memcached is that there are no RAM size limits. Data is automatically persisted and replicated between Triad hub servers. The size of the cache is limited only by the size of hard disks on the host OS. And since it employs optimized native access with memory-mapped files, its efficiency is similar to that of OS virtual memory. If you size the RAM cache properly it performs as well or better than the Memcached daemon.

Version 4.0.24 will support three reference tiers: Web-tier, App-tier, and Memcached-tier. The Memcached-tier can simultaneously provide JCache services to the App-tier as well as support non-Java clients who use Memcached directly. This tiered approach gives you two advantages: massive scale out of the distributed cache system like Memcached, and the speed advantages of an in-process clustered cache. The in-process distributed cache streamlines access to a cache backed by RAM that is not managed by the JVM. However it does not have the same constraints as most in-process distributed cache systems, such as GC pauses and large memory limits imposed by the JVM.

Resin’s distributed cache is easy to configure, use, and works well with the rest of Resin’s support.

More details will follow in the proceeding weeks on data sharding, replication and shard clustering to improve reliability of cache layer while maintaining cloud elastiscity.

Caucho had another great JavaOne in 2011, with well-received sessions by Reza and a high level of interest at the Caucho booth. Theresa, Alexandra, Rick and I were scheduled to split time in our booth, but it was so busy we all ended up spending almost the entire time there. We particularly enjoyed meeting a few current Resin users to get a chance to put a face with the name.

Reza usually does our post-conference wrap-up, but I thought I would take it on this year with the intention of relaying some of the “buzz” of this year’s conference based on discussion with all the folks that stopped by our booth.
(more…)

Do you understand how HTTPS works? Most Java developers will answer, “yes” to this question without much hesitation. In general they’re correct. Public-key cryptography is such a ubiquitous Internet technology that comprehending the theory behind digital certificates and key exchanges is commonplace.

Configuring Resin for HTTP with either OpenSSL or JSSE isn’t terribly complicated either, and the Resin documentation provides a decent reference when you need it. But what most people don’t understand is what all those different key-pair and certificate file formats are, which ones OpenSSL uses compared to JSSE, and how to convert from one format to the other.

The objective of this discussion really isn’t to show you how to create certificates and configure Resin for HTTPS, although that’s included. What I really want to do is review the file formats and encodings used to store keys and certificates, compare and contrast OpenSSL with JSSE, and discuss how to convert from OpenSSL to JSSE and back.
(more…)

Regardless of the operation system you’re running, Resin includes 3 distinct commands for the purpose of stopping the application server. In this tip of the month I’ll explain each command in details, discuss how they differ, and provide some advice on under what circumstance it is appropriate to use each.

(more…)

Resin Pro Health System now and in the future

Resin Pro made significant improvements in its already capable Health System. Improvements include reporting, and post mortem triggering. Resin Pro provides a level of reliability, and system transparency that is unparalleled in the Java EE space. You can see what is going on in every server node in the cloud (or just a single server for smaller shops). If a problem occurs with your code, or with library code that you use, Resin can give you a snapshot of the server state. Imagine just in time profile data and information needed to diagnose a problem. Agile devops!

(more…)

WebSockets is an IETF specification designed to enable more truly interactive browser applications. It creates a message-based system over TCP, after upgrading from a HTTP request. The messages to and from the browser allow for server-sent events and asynchronous notifications. Think of it as a clean implementation of Comet.

The first applications will likely be simple chat improvements, and will become more sophisticated. Google has already demonstrated a Quake implementation.

Resin’s WebSockets API is designed around streams and messages. Each WebSocket message is a traditional Java stream. The message ends when the stream ends.

Your applications receives messages from a listener, because messages are asynchronous and because Resin wants to save threads when no activity is occurring. When your listener finishes Resin will send the next message:

public interface WebSocketListener {
  public void onReadBinary(WebSocketContext context, InputStream is)
    throws IOException;

  public void onReadText(WebSocketContext context, Reader is)
    throws IOException;
}

You’ll want to read the messages quickly and hand them off, because the next message will wait until you’re done with the current message.

Sending messages is also stream-based. Your application starts a new message with a startBinaryMessage() or startTextMessage() call, writes to the OutputStream or PrintWriter, and closes it when the message completes.

public interface WebSocketContext {
  public OutputStream startBinaryMessage()
    throws IOException;
  public PrintWriter startTextMessage()
    throws IOException;
}

Again, you’ll want to write the message quickly because the next message will wait until the current one finishes.

Given that Resin’s Unix installer is a ‘make’ script, and the Windows version includes .dll files, users are often inquisitive about how and why Resin makes use of native code. In this tip of the month I’ll discuss Resin’s native optimizations, what native optimizations are provided in Resin Pro vs Open-Source, and when the native libraries are occasionally required.

(more…)

You have no doubt heard of Java EE Web Profile. In the words of Rod Johnson, founder of the spring framework project, “Java EE 6 Gets it Right”.

Java EE Web Profile is the standard for servers that are more focused on web development using the pieces of the traditional Java EE stack that matter the most. You could say it is all of the stuff with none of the fluff. It allows vendors to create a slim focused application server. In our opinion, it allows vendors to provide an application server that fits the most common case of Java EE development. It has allowed Caucho to focus on what Resin does best, Java EE web development without the distraction of features that our clients don’t use.

(more…)