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. Read the rest of this entry »
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.
Read the rest of this entry »
Resin Cloud Support Overview
Cloud support is Resinâ€™s 3rd generation clustering. It is based on years of perfecting ways to setup and manage a cluster. It is the culmination of decisions about the best way to do things. Caucho has been doing clustering with Resin longer than many other companies existed, and longer than many of the big players were in the Java market. Our clustering predates most if not all other solutions. And our clustering support is not bolted on as an after thought. We didn’t buy it. Caucho is an engineering company. We built it. We perfected it. It is not just built in, its ingrained in. Resin is designed from the ground up to support clustering and cloud computing. Read the rest of this entry »
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.
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!
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:
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.
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.
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.
I just came back from a trip to the Raleigh, NC area to record a JavaLobby Tech Chat on Resin 4 (last year Emil did a Tech Chat that you might have seen). The Tech Chat went great. Mitch Pronschinske, the Editor-in-Chief of JavaLobby/DZone drove the Chat. Not to give away too much right now but we talked about:
- Past/present/future of Resin
- Defining characteristics of Resin - lightweight, standard and feature-complete
- Resin 4 Java EE 6 Web Profile certification
- Java EE Web Profile leadership
- How it stacks up against Tomcat/JBoss/GlassFish/WebLogic/WebSphere
- Small, dedicated, agile World class engineering team
- CDISource - a vendor-neutral space for all things CDI
- The CDISource Spring/CDI bridge
- Possibilities for Java EE 7/Java EE 8 (open for participation from you!)
- Early Resin WebSocket support
- Resin support for private clouds
Keep your eye on JavaLobby - the Tech Chat should be out there soon!
I chose to drive to NC to avoid the hassle of flying and because NC is quite drivable from my home office in Philly. On the way back, I did CDI demos at both the Research Triangle JUG and the NoVA/Washington, D.C. JUG. Both talks were very well attended. The interest/participation levels were fantastic. The DZone folks gave me a few nice printed copies of the CDI RefCard. Every single copy was taken and people were asking for more! They also asked me for the slide deck and code examples. I’ll send them to the JUG leads to post on the JUG websites. You can also take a look at the slide deck and code examples if you want and send me any follow-up questions. I also wanted to talk at the Maryland and Richmond JUGs but things didn’t quite work out schedule-wise this time around. Both JUGs are working on scheduling me to speak in the Fall instead.
What makes a good cloud offering for a Java EE server? What do developers and architects expect from a Java EE vendor to be cloud ready?
I suspect they expect the following:
- Cloud ready
- Elastic ready
- Ability to manage the nodes in the cloud
- Ability to manage versions in the cloud
The advantage we get from deploying applications to the cloud is the ability to scale up processing nodes (Java EE servers) rapidly if needed. And the ability to re-purpose processing nodes (spin down, re-purpose and spin back up) when needed as well. This can be in a public cloud setting like Amazon EC2 or in a private cloud (VMWare vCloud) or some combination thereof.
To be elastic, is to be flexible. The ability to bring up a new node without any configuration.
Ability to manage nodes in the cloud
Once you have nodes deployed in the cloud, how do you manage them? How do you check the health of so many nodes? How do you keep your eye on them all?
Ability to manage versions in the cloud
A common problem with cloud computing and Java EE servers is application archive versioning, war files, and ear files. How do you version a new war file? More importantly, how do you deploy one war file to the entire cloud? Can you deploy a version in a graceful manner without bringing down the entire cloud of nodes?
Resin Java EE 6 application server
Caucho’s Resin server is an elastic cloud ready, Java EE 6 Web Profile server. It has the ability to bring up new instances in an elastic cloud environment. The triad is the brain of the pod. A pod is a collection of nodes that serves some common set of applications. New instances, called dynamic servers, join the pod, talk to the triad and get the current versions of the applications to run. Then they start running the applications.
Cloud aware, load aware, intelligent load balancer
The pod load balancer is smart enough to allow the new dynamic server some time to warm up and install its applications from the triad before it starts sending it requests. The pod load balancer can truly balance the load based on the true load on each node, not just random round robin load balancing. The load balancer can also act as an http proxy cache to increase throughput by caching images, css files and other web resources.
Cloud failover that is cloud deployment version aware
Membership has its privileges, once up, the new dynamic server joins the pod services. It gets reliable, failover sessions. It gets reliable, failover caching. It gets reliable, failover messaging. Everything you would expect from a cloud computing platform like Caucho Resin server.
Now what if for some reason a node in the pod goes down. And then let’s say you deploy new versions of the applications. Then later, we bring that node back up. Does it start serving an old version of the application? No. Of course not. It talks to the triad and gets the current version of the applications.
Our deployment mechanism is truly cloud aware. It versions the deployments. You can even rollback an entire pod to a previous version. You can also gradually deploy a new version of the application. New sessions in the pod will use the new version of the application while existing sessions will use the older version of the application. Eventually all of the older session timeout and only sessions using the new application are active.
Also with Resin you can manage entire pods from load balancer to http proxy cache to triad to individual dynamic servers with a single admin tool. This admin tools allows you to profile, analyze GC, Heap, PermGen, OS memory, monitor threads, inspect memory usage at the class level, and other Java VM graphs and OS graphs from one console for every node in the pod. The support the admin tool provides rivals that of some dedicated profiling tools but does it for your entire pod. Now you can really see what is going on in the cloud.
Health Watches to auto-manage your cloud
You can also setup up health watches so you know when some critical situation has been released and then take some action to monitor, diagnose and control your cloud.
Resin is a Java EE, cloud computing ready server
Resin goes beyond just being a processing node in an elastic cloud. It is truly an intelligent elastic cloud coordinator bringing the promise of cloud computing into the hands of Java EE developers.