Sun Cluster Data Service for Apache Tomcat Guide for Solaris OS

Configuration Restrictions

The configuration requirements in this section apply only to Apache Tomcat.

Caution – Caution –

If your data service configuration does not conform to these requirements, the data service configuration might not be supported.

Restriction to deploy Sun Cluster HA for Apache Tomcat in a scalable configuration

Deploy a scalable Sun Cluster HA for Apache Tomcat configuration only if either session replication, or reliable source ip addresses are achieved. Otherwise the behavior of the application becomes unpredictable.

Restriction for the Load_balancing_policy

Setting the resource parameter Load_balancing_policy to LB_STICKY is strictly required, if Sun Cluster HA for Apache Tomcat is deployed in a scalable configuration with reliable source ip addresses when no session replication is configured. Otherwise, the behavior of the application becomes unpredictable. In every other scalable configuration the Sticky Load_balancing_policy helps to get the more cache hits out of your caches.

Restriction for Scalable Services and Solaris Containers

Sun Cluster HA for Apache Tomcat can be deployed in scalable configurations in Solaris Containers only if you use the zone features of Sun Cluster 3.2.

Restriction for the Apache Tomcat smf Service Name in a Failover Zone

The Apache Tomcat configuration in a failover zone uses the smf component of Sun Cluster HA for Solaris Containers. The registration of the Apache Tomcatdata service in a failover zone defines an smf service to control the Apache Tomcat database. The name of this smf service is generated in this naming scheme: svc:/application/sczone-agents:resource-name. No other smf service with exactly this name can exist.

The associated smf manifest is automatically created during the registration process in this location and naming scheme: /var/svc/manifest/application/sczone-agents/resource-name.xml. No other manifest can coexist with this name.