Resin 5.0.0 - alpha (2014-06-12)¶

alpha status
Distribution and packaging changes
Feature focus (servlet, jsp)
Command-line changes
Configuration simplification
Deployment
Baratine (Service Architecture)
Bartender (Clustering)
Kelp/Kraken (Internal Database)
HTTP/2.0
Load Balance Proxy to HTTP/2.0
HTTP cache updates
Websocket
Logging

Alpha Status¶

Resin 5.0.0 is considered to be in alpha status. Since there are known reliability and performance issues, it is not likely to be suitable for external deployment yet, and should be considered a preview release.

Distribution and Packaging¶

The runtime has been simplified so Resin can run as a single, independent jar, defaulting to a working directory in /tmp/resin, which allows simple deployments and testing to work immediately without additional configuration.

Startup has been simplified as well. A webapp can be deployed in a new Resin configuration without additional directories or configuration:

$ bin/resin start --deploy ROOT.war
Resin/5.0.s140618 start with watchdog at 127.0.0.1:6600
Resin/5.0.s140618 launching watchdog at 127.0.0.1:6600
  starting *:8080 (cluster-8080)
  deployed hello.war to bfs:///system/webapp/deploy/cluster/host/hello/hello.war

Or directly from a jar:

$ java -jar lib/resin.jar start --deploy ROOT.war

The main command-line can also be called directly from frameworks like eclipse:

import com.caucho.cli.resin.ResinCommandLine;

ResinCommandLine.main(new String[] { "start" });

resin.jar¶

The resin.jar is now complete and self-contained, including JNI support for Linux and Mac, and embedded configuration. It has also been simplified to a single jar of around 10M.

Root Directories¶

The default root working directory is in /tmp/resin. It can be easily changed using the “-d” or “–root-dir” option from the command line.

Default Configuration¶

The resin.jar contains a default configuration that is complete for many simple configurations. The HTTP port can be changed from the command-line with -p or --port without needing extra configuration.

Feature Focus¶

Resin 5.0 has focused on the core servlet specifications:

* Servlet
* JSP
* EL
* CDI
* WebSocket

HTTP services have also been focused:

* HTTP/2.0
* Load Balance/Proxy using HTTP/2.0
* HTTP Cache
* Session distribution and persistence
* URL rewriting and dispatch

Other features that were used less frequently have been dropped, including EJB, JCA, JMS, jCache.

Command-Line¶

The command-line has been extended and organized. While the examples below use bin/resin, the command-line is identical when used from resin.jar or directly from ResinCommandLine.

Starting the server, protected by the watchdog:

$ bin/resin start

Shutting down the watchdog and all servers:

$ bin/resin shutdown

Deploying a war:

$ bin/resin deploy -n ROOT my-war.war

Start and deploy:

$ bin/resin start --deploy ROOT.war

Start with an alternative port:

$ bin/resin start -p 8082

Start with Resin 5 config file and alternative root directory:

$ bin/resin start -d /var/resin --conf /etc/resin/resin.cf

Start with Resin 4.0 compat config file:

$ bin/resin start -d /var/resin --conf /etc/resin/resin.xml

Start in the foreground in a single JVM, without the watchdog:

$ bin/resin start -fg

View debugging file:

$ bin/resin cat /proc/servers

Benchmarking:

$ bin/resin -n 10 bench-http http://localhost:8080/hello.jsp

Command-line scripts:

$ bin/resin -i my-script

Where the script might be a single JVM stress test that starts Resin in the shell JVM (-bg), deploys a test, and then starts the benchmark:

start -bg -p 8099
deploy test.war
sleep 2
bench-http -n 1000 http://localhost:8099/test/hello.jsp
bench-http -n 100000 http://localhost:8099/test/hello.jsp

Configuration Simplification¶

Resin 5.0 configuration is now simplified both in syntax and with default templating, which minimizes the configuration new Resin users will need. For a single server installation, no configuration is needed.

The new templating mechanisms means that configuration can focus on what’s needed. Adding servers can be done without needing to include standard servlet configuration. For example, a cluster of three servers would have a resin.cf like:

cluster {
  server 192.168.0.10 80;
  server 192.168.0.11 80;
  server 192.168.0.12 80;
}

Unlike Resin 4, the web-app and servlet configuration is not required in the resin.cf, because those items are configured with a template, resin.tmpl.cf. Although sites can override the template, the default configuration will be sufficient for most.

Backwards Compatibility Configuration¶

Resin 4.0 configuration is supported in Resin 5.0. If the –conf` value is an XML file, Resin 5.0 will parse it as a Resin 4.0 configuration file. The structure of the configuration is identical.

Deployment¶

In Resin 5.0, the standard .war deployment is through the command line. The deployed .war will be saved in an internal database, and expended in the Resin working directory that defaults to /tmp/resin. In a clustered environment, the deployed .war will be distributed to all servers in the cluster.

A sample command-line deployment:

$ bin/resin deploy -n root my-app.war

For backwards compatibility, the older webapps directory can be configured with a Resin 4.0 configuration file.

Internal Deployment Implementation¶

Resin 5.0 uses an distributed filesystem (BFS) for deployment. The new filesystem replaces the Resin 4.0 git-based distribution. Deployed .wars can be viewed using command-line filesystem commands: ls, cat, get, put.

Internally, the replication, persistence and distribution now use the same underlying systems as session replication. (Resin 4.0 distribution was implemented as a separate system.) Using one system in Resin 5.0 simplifies the implementation, and improves Resin’s internal testing.

Baratine¶

Internal services in Resin 5.0 now use Baratine. Baratine is the successor to the Resin 4.0 BAM framework, updated based on our experience with Resin 4.0.

Using these services in Resin has eliminated several complicated multithreaded systems, and replaced them with fast single-threaded services. By reducing the synchronization, these services are simpler to maintain, and can be faster.

Bartender (Clustering)¶

Clustering services like deployment and sessions now use Bartender for cluster management. Bartender replaces the heartbeat mechanism in Resin 4.0.

Advantages in Resin 5.0 clustering include better support for cloud environments like EC2, increased reliability with better heartbeating, and transforming cluster into the single-threaded Baratine services, simplifying or eliminating synchronization issues.

The new Resin 5.0 “pod” concept replaces the Resin 4.0 “triad”, where the triad is a specific case of the pod. Pods can be organized as triad, or “solo”, or “pair” or “cluster”.

Deployment and session replication use Bartender to save deployment files and locate sessions.

Kelp/Kraken (Internal Database)¶

The internal database used for deployment, session replication, and admin statistics has been completely rewritten and redesigned for better reliability and write performance.

write-only files
journaling
single-threaded (Baratine) writer

The write-only file format of the new database (Kelp/Kraken) reduces database corruption. Because updates do not overwrite old data, there are fewer opportunities for timing problems or failures.

Journalling of inserts and updates improves performance and reliability. Before updates are written to disk, they are written to a fast log. On recovery, the log can be replayed. The log minimizes database writes, because the database can update in memory and then batch writes to disk.

Using a Baratine service for writes has reliability and performance benefits. Because the writer is single-threaded, locking is not needed, and debugging and testing is simplified. The single thread can also help write performance by improving the CPU cache behavior by minimizing write contention and cache use.

HTTP/2.0¶

HTTP/2.0 (draft 12) is now supported. HTTP/2.0 is a binary version of HTTP which improves TCP efficiency by allowing multiple asynchronous requests on a single TCP socket and reducing header size.

Load Balance Proxy¶

The load balance proxy, which forwards requests from a Resin web-server to a Resin app-server, now uses HTTP/2.0. The Resin web server can now load-balance to any backend servers that supports HTTP/2.0, and Resin can be an app-server to any web-server that supports HTTP/2.0 as a proxy.

HTTP Cache Updates¶

The HTTP cache is now enabled by default. Internally, it’s backing store has been updated to use the same low-level mmap segment reading and writing as the internal database.

WebSocket¶

WebSockets are supported with the Java standard WebSocket specification.

Logging¶

Logging supports patterns based log4j syntax. Logging now uses an asynchronous service for scalability.

.git source¶

The Resin source is available in git as: git://git.caucho.com/baratine.git and git://git.caucho.com/resin.git.

When building Resin, you will need to build Baratine first.