Resin Architecture

Resin Smart Load Balancer

As traffic increases beyond a single server, Resin’s load-balancing lets you add new machines to handle the load and simultaneously improves uptime and reliability by failing over requests from a downed or maintenance server to a backup transparently.

<resin:LoadBalance> is part of Resin’s rewrite capabilities, Resin’s equivalent of the Apache mod_rewrite module, providing powerful and detailed URL matching and decoding. More sophisticated sites might load-balance based on the virtual host or URL using multiple tags.

Documenation: Smart Load Balancing

Once your traffic increases beyond the capacity of a single application server, your site needs to add a HTTP load balancer as well as the second application server. Your system is now a two tier system: an app-tier with your program and a web-tier for HTTP load-balancing and HTTP proxy caching. Since the load-balancing web-tier is focusing on HTTP and proxy caching, you can usually handle many app-tier servers with a single web-tier load balancer. Although the largest sites will pay for an expensive hardware load balancer, medium and small sites can use Resin’s built-in load-balancer as a cost-effective and efficient way to scale a moderate number of servers, while gaining the performance advantage of Resin’s HTTP proxy caching.

Resin HTTP Proxy Cache

Server caching can speed dynamic pages to near-static speeds. When pages created by database queries only change every 15 minutes, e.g. CNN or Wikipedia or Slashdot, Resin can cache the results and serve them like static pages. Because Resin’s caching only depends on HTTP headers, it will work for any JSPs, servlet or PHP page.response.

Resin’s caching operates like a proxy cache, looking at HTTP headers to compare hash codes or digests or simply caching for a static amount of time. Since the proxy cache follows the HTTP standards, applications like Mediawiki will automatically see dramatic performance improvement with no extra work. You can even cache REST-style GET requests.

Documentation: Proxy Cache

Because the cache supports advanced headers like “Vary”, it can cache different versions of the page depending on the browser’s capabilities. Gzip-enabled browsers will get the cached compressed page while more primitive browsers will see the plan page. With “Vary: Cookie”, you can return a cached page for anonymous users, and still return a custom page for logged-in users.

Resin Application Server

Highly interactive web applications for tablets and phones will dominate the web in the next generation. Caucho’s relentless quest for performance and reliability paved the way for Resin Java Application Server to be a leading open source web and application server. Our Java EE Web Profile implementation includes Servlet, JSP, JSTL, EJB Lite, CDI, JSF, JMS and others. Resin provides an ideal environment for lightweight web development – where you can deploy a fast and highly responsive site.

Resin was the first Java EE Web Profile certified Java application server. Resin 4 is built from the ground up around Java Dependency Injection (CDI). Resin 4 is optimized to work in cloud computing environments like Amazon EC2.

• Versioned Deployment
• TWO SECOND startup
• Embeddable
• Testable with JUnit
• Low Memory Profile

With built-in support for both internal and external virtualized
environments, Resin makes it possible for existing applications to
take advantage of an elastic infrastructure. Our clustering supports
running multiple versions of the same application within the same
server so that upgrading requires zero downtime. Resin’s cloud support
includes remote cluster-wide and synchronized application deployment,
data and session replication, failover to improve reliability and
responsive dynamic servers.

Documentation: Enterprise Clustering for Cloud Environments

Short Video with Animations Describing Resin Cloud Support

The Resin 4 core and configuration is built around the Java EE
standard CDI dependency injection. Every Resin configuration from the
resin.xml to resin-web.xml uses CDI as its configuration engine. CanDI
is Resin’s implementation of Java CDI and it is core to Resin 4 Java
Application Server.

Resin Distributed Cache

Java caching can speed application performance and lower database load by annotating cacheable methods. Resin application server that supports both CDI and JCache, you can add caching easily without much configuration. It uses the method parameters as a cache key, and stores the method result in the cache. On the next method call, the enhanced method will look for the saved result in the cache, and return it, saving the effort of the method.

You’ll want to cache to:

• Improve latency
• Reduce database load
• Reduce CPU use

Resin Cache features:

• Larger cache size – based on host OS disks and not RAM size
• Automatic data persistence
• Triple redundancy backed by Triad servers
• Interface with JCache
• Garbage Collection-less (GC-less) in-memory cache
• Cache dynamically updated in cloud environment
• Memcached wire protocol support

“Resin’s cache support is fast, durable and fully elastic,
allowing for the addition or removal of nodes as needed without
getting extra hits to your database. We also provide a JCache
interface, so you can have characteristics of an infinite cache
or fine grain controls and configuration of caches, as per JCache
(JSR 107, which we track closely). If you use JCache, we have
implemented a GC-less in-memory cache; if the item is in this
first level cache then the performance can be 1000x faster than
going an external cache. This is an easy setup that provides
in-memory speeds to applications.” – Scott Ferguson, Software Architect at Caucho Technology.

Resin Adaptive Health Monitoring

Because your site’s reliability is important, Resin monitors its internal sensor net every 60 seconds, recording your server’s memory, cpu, network, database and cluster status. Resin monitors JVM metrics, Java Application Servers metrics and OS metrics. The Resin JAMM saves the data so you can adjust the servers based on load, and can analyze problems after they occur. The data is saved so Resin can identify trends and anomalies.

Each 15 minutes, the health system checks the sensor data and reports a status: OK, WARNING, CRITICAL or FAIL. You can direct Resin’s health system to act based on the health check results, mailing a notification, gathering further thread and memory information or even restarting.