Since I published Part 1 of the Resin Command Line Overview we’ve added a few more commands. The added commands allows to enable or disable a server, add a license, deploy new configuration files and generate admin password. Today I hope to cover commands I did not cover in part on and the new commands. (more…)
Archive for the ‘Uncategorized’ Category
Conditional Configuration Using Functions and Expressions
This second part of a multi-part article on Resin configuration examines how to employ conditional XML statements and EL functions to simplify Resin configuration. When we’re done, you’ll understand how the same configuration could be shared between deployment environments with entirely different Resin operation by using some following concepts:
- Conditional XML with <resin:if>, <resin:when>, <resin:choose>, <resin:otherwise>
- Null checking with â€œthe Elvis Operatorâ€ ?:
- Regular expression matching with =~
- Resource access with mbean() and jndi()
Charles Humble talks to Paul Cowan about the Resin Application Server architecture, capabilities, and where it fits in the Cloud market. You can see the video interview on InfoQ.
I got started about 11 years ago. I was weaned on Java and started with NetDynamics which (some people maybe remember) was one of the first JEE servers to come out. Iâ€™m primarily a backend software developer, have been doing threading and concurrency caching for the last few years, and recently at my work with Caucho, Iâ€™m mostly working on the health system, our health monitoring system, and get involved in some of the CDI implementations or web servers - pretty much anything that we need to work on at Caucho in terms of the Resin application server.
We see Resin as an elastic JEE application server layer. We are not a Platform-as-a-Service and weâ€™re not a Software-as-a-Service, weâ€™re a Platform-as-a-Service or Software-as-a-Service infrastructure provider or vendor. But we donâ€™t sell the service; we donâ€™t provide it to you.We just sell you the software and you build your Cloud on it.
We have seen consistently growing interest in running Resin on Amazon EC2. EC2 is an Infrastructure as a Service (IaaS). It provides hardware, networking, load balancing, connectivity, storage and virtualized OS hosting. Resin 4 includes cloud support features that make deploying to EC2 simple and painless. Resin offers dynamic clustering, load balancing and versioned deployment. A comprehensive health monitoring system provides visibility into the status of your entire application stack. Furthermore, comparing Resin to PaaS providers, Resin is really a PaaS-ready application server; one that will run well on an IaaS service like Amazon EC2.
This is part two of a tutorial on using Amazon EC2 and Resin to do cloud deployment. 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.
RunningÂ Euca Tools to launch Amazon EC2 instances.
Make sure to complete part 1 first.
This is an extension of this tutorial Resin Cloud Deployment with Amazon EC2.
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.
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.
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.
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.
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.