Monthly Archives: January 2017

Caucho Newsletter January 2017

paradise-sky.jpg  
   
    
​  Celebrating 19 years as the #1 Java app server!

Sun_with_Sunglasses_Transparent_Picture.png"Though it rarely happens, whenever one of our domains goes down, Resin's watchdog monitor restarts it automatically. We have been using Resin for five years and have achieved 99.99% up time. It is very reliable and fast. We host several websites and we particularly like the ability to run each domain in its own isolated java virtual machine”

- Peter BetBasoo, Assyrian International News Agency

 

Resin 4.0.50 will be available for download this week on caucho.com/download. With many new fixes in the latest release, the number of open requests is down to 15! We recommend upgrading to the latest version for the highest performance and stability.

Notable bug fixes in 4.0.50:

  • 0006027:  ref #6009: Shutdown doesn't appear to give requests time to finish
  • 0006025: add ignore-lock
  • 0006023: NPE: tld discovery
  • 0006022: command jmx-list -operations NPE
  • 0005990: IndexOutOfRangeException in Caucho.IIS.LoadBalancer.OpenServer
  • 0005948: apr_pool_cleanup_register(config->web_pool, s, cse_cleanup_, NULL) at modules/c/src/common/stream.c:1848 cause segfault
  • 0006021: JSTL Custom tag upper to lowercase
  • 0006002: add custom global error page for 503 service unavailable
  • 0005918: resin crashes on server shutdown on windows with openssl
  • 0005916: OPENSSL: SIGSEGV
  • 0006017: db pool issues when full
  • 0006020: Resin.properties defaults with persistent sessions on
  • 0005969: forward in include with context /foo
  • 0006008: resin:Forward at host level does not forward if @regexp matching context exists
  • 0006015: Allow server id be muted on error pages
  • 0006014: proxy-cache not showing updated files
  • 0005957: Deployment of war file causes Java to use 100% CPU and Resin to crash
  • 0005989: Resin pauses for 30 or more seconds during startup performing some git operations

For bug fixes, email us at presales@caucho.com or submit bugs directly at http://bugs.caucho.com/main_page.php
 

Resin High Availability – easy default setup!
 

We want to make sure you are getting the best out of your Resin deployment. Through best practices gathered from emails, phone calls, and on-site visits, we continue to craft the default setup of Resin as a High Availability setup. To this end, we have put together a two-part overview that describes this setup.

 

The purpose of this overview is to familiarize new users with the architecture and configuration of Resin, and cement what long-time users may already know. As always, we value your feedback so take a look and feel free to send your comments to wiley@caucho.com.

Overview – Part I

Running a web application in high availability configuration requires a Resin Cluster. Resin cluster is a feature of Resin Pro which provides load distribution and session and cache replication.

 

In a minimal configuration with two application servers load can be split in two, with each server serving 50% of requests. In such a cluster consisting of two servers, sessions can be maintained in-memory or can be replicated between the two servers with each server has a copy of a every live session. This determination is dependent upon the session_store property in the resin.properties file which defaults to false.

 

A suggested Resin High Availability cluster with failover support should have three or more servers. Such configuration ensures that sessions and distributed cache data are triplicated providing extra redundancy for session data.

 

The core three servers of the cluster should be configured as static servers in resin.properties file. These three servers will construct the cluster core with each storing a full copy of all live sessions and distributed cache data.

 

Additionally a Load Balancer is required to balance load between cluster peers. Resin Pro provides Load Balancing capability as one of the core features of its Web Tier. If a hardware load balancer is used instead, it should be capable of supporting sticky sessions i.e. be capable of forwarding all requests from one client to the same Resin server. Sticky sessions help make the most efficient use of Resin cluster as each request is forwarded to the server where corresponding session was originated.

Configuration Files Overview

Default installation using:

1.  ./configure

2.  make

3.  sudo make install

will install Resin configuration files in the in /etc/resin directory

Resin Properties File

Named resin.properties the file configures values for Resin Pro standalone and Resin Pro cluster. Values from resin.properties are imported into resin.xml and cluster-default.xml

Resin Configuration File

Named resin.xml the file provides configuration for application and web (load balancer) clusters. File resin.xml imports values from resin.properties

Resin Default Configuration Files

Resin extracts default configuration into cluster-default.xml, app-default.xml files. Default configuration is imported into resin.xml and should rarely be changed.

Default Cluster Configuration

By default clusters for application and Web Tiers are defined in resin.xml. Application tier is used for hosting web applications while Web Tier is used for load balancing. Typically, requirements for Web Tier may not be as high as they are for App Tier which makes using fewer Web Tier servers with more servers in the App Tier possible.

Web Tier servers provide load balancing and web content caching, reducing load on the servers in App Tier.

Configuring App Tier Cluster in resin.properties:

Resin.xml exports server configuration for app and web clusters into resin.properties.

Servers for App and Web tiers are mapped to app_servers and web_servers properties respectively.

Excerpt below shows how to configure three servers in the App Tier cluster; let the App Tier ips range be between 192.168.1.10 and .19

Dynamic Servers

Both App Tier and Web Tier clusters support dynamic servers. Dynamic servers can be taken in and out of rotation on an as needed basis.

Enabling dynamic servers requires setting the following property in resin.properties
Jan_NL_PIC A

  

Starting Servers in the App Tier

Servers defined statically in resin.properties needs to start first. They will form the core of the cluster. Since the first three static servers compose the cluster core, cluster will operate normally as long as at least one of those servers is operational.

Starting the servers is achieved with bin/resinctl start –server app-33443 command.
Jan_NL_PIC B1
Jan_NL_PIC B2
​The 33443 parameter comes from the position of the server in app_servers (or web_servers )property.
 
For example server 192.168.1.10:6800 should be started with command:

Jan_NL_PIC C

Starting Dynamic servers in the App Tier

After static servers are started dynamic servers can join the cluster. Let the dynamic servers ip range start with 192.168.10.20 and start two dynamic servers:
Jan_NL_PIC D
Note, that the command requires specifying the ip and port to which to bind the new dynamic server. Note also, that specifying cluster name is required as well.

The cluster name maps to servers in the cluster using cluster servers property defined in resin.properties. All servers in the cluster should be using identical configuration i.e. they should all share the same resin.xml and resin.properties file, along with cluster-default.xml and app- default.xml if these files were changed.

Jan_NL_PIC E

Configuring Web Tier Cluster

Web Tier cluster exports its server configuration into web_servers property. Configuring the Web Tier servers is identical to configuring the App Tier's. Both tier clusters support adding dynamic servers.

Let the Web Tier have ips range start with 192.168.1.80:

 Jan_NL_PIC F 

Web Tier servers can be started independently of App Tier but the Web Application will start being served only after servers of the App Tier become operational.

Stay tuned for Part II in the next Caucho newsletter!

Resin Tip – Secure Virtual hosts Redirect
 
Did you know that you can issue secure redirects in Resin at the host level? This setup is advantageous for users who might use a load balancer listening on their secure port to redirect traffic to Resin. By having the response from Resin secure, you can avoid a “double redirect” for your traffic.
 
There are two ways to configure the host for the redirect.
 
1. Add a <host-name> to the <host>.
 
<host id="" host-name="https://www.foo.com">
     …
</host>
 
The redirect will use the host-name when filling in the redirect. That assumes you've got a single fixed virtual host, of course.
 
2. Add a secure="true" to the <web-app>.
 
<web-app secure="true">
     …
</web-app>
 
That secure="true" will tell Resin to assume the real connection is secure even though Resin itself isn't using an SSL connection. So redirects will use “https:” instead of “http:”.
 
 

New Years gift to optimize your configuration!
 
Contact Caucho engineer Sean Wiley at wiley@caucho.com or (858) 456-0300 to set up a complimentary review of your deployment, including learning about new Resin features and tips to optimize your configuration.

Download Resin                                                   Facebook: Caucho Technology  Resin Twitter page

paradise-beach.jpg