Resin Application Server and Cloud discussed by Paul Cowan

Resin Application Server
Paul Cowan - InfoQ
Interview
Caucho Home | Contact Us | Caucho Blog | Wiki | Application Server

InfoQ - Paul Cowan Discusses the Resin
Application Server and Cloud

About Paul Cowan
• Software Engineer working on the Resin
application server at Caucho Technology

• Focusing on dependency injection,
concurrency, high-speed messaging, and
distributed caching

• 11 years of experience
• Started with NetDynamics
• Prior to Caucho worked as Senior Architect
with NAVTEQ
• Traffic.com division


“Where do you see Resin
in terms of the wider
Cloud landscape?”


Resin and the Cloud
Landscape
• Resin ﬁts on the elastic JEE application layer
• We don’t sell the service or provide it to you
• Not PaaS
• Not SaaS
• We are a infrastructure provider/vendor
• You get the Resin software
• You build your Cloud on it


“Can you tell us a little bit
about how your Cloud
support is architected?”


Resin Cloud Support
Architected
• Triad hub-and-spoke
architecture

• Hub
• Three Primary Servers
• Constantly
communicating with
each other

• Spoke
• Elastic Spoke Servers
• Add or Remove as


“Why did you go for a
hub-and-spoke rather
than say a peer-to-peer
cluster?”


Hub-and-Spoke vs. Peer-
to-Peer
• Most cases easier to have 3 primary servers
• IP addresses are known
• No need for auto-discovery
• Creates problems in EC2 environments

• Hub architecture with 3 primary servers
• Responsible for caching data
• Maintaining the knowledge of Cloud architecture
• Eliminates a lot of issues you get with true peer-to-
peer network


Basic Hub-and-Spoke
Conﬁguration

Dynamic&&
Spoke&
Server&
Triad& Triad&
A&
Server& Server&
1& 2&

Triad&
Server& Dynamic&&
3& Spoke&
Server&
B&


Basic Hub-and-Spoke
Conﬁguration
Load(increases.(
Spin(a(new(server((
Dynamic&& Dynamic(( up(
Spoke& Spoke(
Server& Server(
Triad& Triad&
A& C(
Server& Server&
1& 2&

Triad&
Server& Dynamic&&
3& Spoke&
Server&
B&


“How do you keep the network
traffic to a reasonable level as
the number of spikes grows?”


Keeping Network Traffic at
Reasonable Level as Spikes
Grow
• Messaging based on Hessian Network Protocol
(HMTP)

• During distributed sessions
• Only update your session data when the data
changes
• Hashing session
• Triad master will have a hash of what current data is
• Spoke server veriﬁes latest data
• “Here is my hash, do I have the latest data?”
• If hashes match very little data needs to be sent


New Server Dynamically Joining
Cloud

Dynamic((
Spoke(
Triad&Server&1& Server(
192.168.1.10& A(

Triad&Server&2&
192.168.1.11&

Triad&Server&3&
192.168.1.12&


New Server Dynamically Joining
Cloud
Spin up a new VM instance and add it to the cluster. It talks to the triad to
join

Dynamic((
Spoke(
Dynamic((
Spoke(
Ask for latest
Triad&Server&1&
192.168.1.10&
Server( Server(
B(
application
versions
A(

Triad&Server&2&
192.168.1.11&

Triad&Server&3&
192.168.1.12&


“How do I conﬁgure the
typology of the cluster?”


Configuring Typology of
Cluster
• Resin keeps it simple
• Primarily a single JAR file with configuration file
• Same configuration file
• Triad
• Web tier
• Any cluster tiers
• Spokes

• Triad servers spun up
• Usually static on different machines


Conﬁguring Typology of
Cluster
• Elastic servers spun up
(continued)

• Using single command line
• Easy to bring them up and down as needed


“How does Resin support Cloud
deployment and distributed
versioning?”


Cloud Deployment and
Distributed Versioning on Resin
• Based on HMTP messaging system
• Forms basis for distributed cache
• Distributed versioning based in Git
• Internal version of Git library
• Pushing a WAR or an application to Triad servers
• Git is used to internally push out to all other servers


Cloud Deployment and
Distributed Versioning on Resin
(continued)
• Sessions in Cloud are tied to Git version of
application
• A number of sessions running off one version of
application
• Push a new version
• Resin keeps that version of application until all
sessions are over
• New sessions coming in will get new version of
application


“You’ve got replicated session
state across the machines?
What’s the overhead like for
that; for actually replicating the
session?”


Overhead for Replicated Session
State Across Machines
• Pretty low
• Only need to replicate to the server that is handling that
session

• Using sticky sessions
• With a lease
• Same session goes to the same server and push session
update to Triad

• Conﬁgurable
• When to Push
• Push after every update


Overhead for Replicated Session
State Across Machines (continued)
• Hashing sessions and comparison with master
and spoke servers
• Cuts down on network traffic


“What’s the Watchdog
system and why is that
important for Cloud
deployment?”


Watchdog System
• Resin always runs with two processes
• Watchdog is the secondary process that
controls Resin

• When you start up a Resin server
• Watchdog starts up ﬁrst and starts up Resin for you
• Monitors health of Resin system
• Automatically restarts if there is an issue


Watchdog System
(continued)

• Cloud environment advantage
• Watchdog system maintains health of servers
• Prevents losing track of elastic servers
• Reports any noticed issues
• Health system is external process
• Can detect when Resin is having issues


“Can you describe some
of the other reports I can
get out of the health
system? You have post-
mortem reports for
instance.”

Health System Reports
• Watchdog Report
• Prior to or leading up to a restart
• Produce a report from the data we were tracking at the
time

• PDF Report
• Tread dump
• Heap dump
• Stack dump
• JMX dump


Health System Reports
(continued)

• PDF Report (continued)
• Goes through all JMX
• Dump out attributes and values
• Can do profiling if you want
• Internal native profiling library
• Can profile for a period of time
• Monitoring other attributes in system, for example:
• CPU Usage
• Memory usage
• File descriptors
• Produces a “snapshot” PDF


“And you do JIT proﬁling
as well, I think I’m right in
saying?”


JIT Proﬁling
• Health system is very conﬁgurable
• Any period of time
• From a certain end response to a certain issue


“How does what you offer
compare to some of the other
JavaEE vendors? WebLogic has
some similar features, for
instance.”


Comparing Resin to other
JavaEE Vendors
• Positioned between Tomcat and WebLogic
• Enterprise quality server
• Elastic
• Health System
• Administration System
• More lightweight
• Only 23 MB download
• 6 second start-up time


Comparing Resin to other
JavaEE Vendors (continued)
• For customers who want enterprise quality that
don’t need the heavyweight full JEE stack

• Support JEE 6 Web Proﬁle


“You also have an
anomaly detection
feature. Could you tell us
a bit about that and where
that idea came from?”

Anomaly Detection
Feature
• Organically rose from need to support
customers
• As well as a lot of our health system
• Result from an actual customer having thread
spike issues
• Noticed the issue in produced graphs
• Unable to tell what was happening
• Needed a snapshot at the time of issue


Anomaly Detection
Feature
• Monitors virtually any statistic in your JMS
(continued)

• i.e. number of threads
• Sees unusual spike in amount of threads
• Snapshot report is triggered

• Invaluable in providing support
• Detecting something unusual happening while its
happening
• Creating a snapshot of the system to use for
debugging


Resin Application Server and Cloud discussed by Paul Cowan

Recomendados

Recomendados

Mais conteúdo relacionado

Último

Último (20)

Destaque

Destaque (20)

Resin Application Server and Cloud discussed by Paul Cowan

Notas do Editor