Interview
My Bookmarks
Login or Register to enable bookmarks for unlimited time.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Recorded at:
Paul Cowan Discusses the Resin Application Server and Cloud
Interview with Paul Cowan by Charles Humble on Dec 21, 2011 Length 00:12:31 Download: MP3
- Sections
- Development
- Topics
- JavaOne2011 ,
- Java One ,
- Application Servers ,
- Java ,
- Web Servers ,
- PaaS ,
- Web Development ,
- Cloud Computing ,
- Resin
Share
|
|
Problems watching video?
Summary
In this interview Charles Humble talks to Paul Cowan about the Resin Application Server architecture, capabilities, and where it fits in the Cloud market.
Bio
Paul Cowan is a Software Engineer working on the Resin application server at Caucho, focusing on dependency injection, concurrency, high-speed messaging, and distributed caching. Prior to joining Caucho Paul worked at NAVTEQ, where he was a senior architect in the Traffic.com division. He has 11 years of experience with Java and application servers, starting with NetDynamic.
About the conference
JavaOne is all about exploring Java and related technology. From special exhibitions to demos and partner offerings to community networking opportunities, you'll find an endless source of inspiration as you explore JavaOne 2011. JavaOne offers the best Java-focused content, training and networking.
In this interview Charles Humble talks to Paul Cowan about the Resin Application Server architecture, capabilities, and where it fits in the Cloud market.
Bio
Paul Cowan is a Software Engineer working on the Resin application server at Caucho, focusing on dependency injection, concurrency, high-speed messaging, and distributed caching. Prior to joining Caucho Paul worked at NAVTEQ, where he was a senior architect in the Traffic.com division. He has 11 years of experience with Java and application servers, starting with NetDynamic.
About the conference
JavaOne is all about exploring Java and related technology. From special exhibitions to demos and partner offerings to community networking opportunities, you'll find an endless source of inspiration as you explore JavaOne 2011. JavaOne offers the best Java-focused content, training and networking.
My name is Charles Humble and I’m here with Paul Cowan, Senior Software Engineer at Caucho Technologies. Can you tell us a bit about yourself and your work at Caucho?
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.
Where do you see Resin in terms of the wider Cloud landscape?
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.
Can you tell us a little bit about how your Cloud support is architected?
We have what we call a Triad hub-and-spoke architecture; the Triad being three servers that are your primary servers that are in constant communication with each other. That forms the hub, and then n number of elastic spoke servers that you can add and remove, as needed, to handle the load.
Why did you go for a hub-and-spoke rather than say a peer-to-peer cluster?
What we found was that in most cases it ends up being easier to have these three primary servers, with IP addresses that are known, without this auto-discovery, because really that creates a lot of problems in EC2 environments. The hub architecture of the three primaries, that are responsible for caching the data and maintaining the knowledge of the architecture of the Cloud, eliminates a lot of issues that you get with a true peer-to-peer network.
How do you keep the network traffic to a reasonable level as the number of spikes grows?
Our messaging is based on what we call HMTP which is our Hessian Network Protocol over the web socket standard. What we are doing is we’re looking at, for example, in the distributed sessions we will usually only update your session when the data changes and, even then, we’re hashing the session and the Triad master will have a hash of what the current data is. The spoke servers will say, "Here is my hash. Do I have the latest data?" If the hashes match, then you don’t need to send very much data.
How do I configure the typology of the cluster?
Resin is really simple and it’s primarily just a single JAR file with a configuration file. It’s the same configuration file for the Triad as it is for the web tier, any of the cluster tiers, the spokes. The three Triad servers are spun up and they are usually static on different machines, and the elastic servers are spun up just with a single command line. It’s really easy to bring them up and take them down as you need to.
How does Resin support Cloud deployment and distributed versioning?
It’s based on our HMTP messaging system, which I mentioned before. That forms the basis for our distributed cache and then our distributed versioning is based on a Git. So we have an internal version of the Git library and when you push a WAR, an application, to one of the Triad servers, we use Git internally to push it out to all the other servers. Sessions in our Cloud are tied, usually, to the Git version of the application, so you can have a number of sessions running off of one version of the application, push a new one, and then Resin will keep that version of the application up until all the sessions are over, and then new sessions that are coming in will get the new version of the application.
So that’s the graceful version upgrade feature, isn’t it?
Yes, that’s how you upgrade. Alternatively, you can bring a server down, put the application on there, bring it back up. That’s an option the Cloud is auto-sensing and will move the load around, or the other alternative is to have a set of servers that you upgrade and then basically flick a switch on your load balancer and move your load to the other servers.
You’ve got replicated session state across the machines? What’s the overhead like for that; for actually replicating the session?
Yes. It’s pretty low, because you only need to replicate it to the server that is handling that session. We’re using sticky sessions, with a lease. So the same session will go to the same server and it will push its session update to the Triad. Now, that’s configurable whether you want it to push after every update or if you want to push it after a time period. The hashing of the sessions and comparison with the master and the spoke servers is what cuts down on the network traffic.