View comments | RSS feed
JRun Administrator's Guide Previous Up One Level Next
Clustering


Overview of clustering in JRun

Real-world applications require predictable availability and response time. One way to assure availability and consistent response time is to define clusters of servers to handle web and enterprise applications. A cluster is a set of servers that provide a single system image, and manage application load and server load across the servers that participate in the cluster. Managing load across a cluster involves the following facets:

JRun supports the following types of clustering:
Type
Description
For more information
Web server connector clustering
The web server connector manages HTTP requests among the JRun servers in a cluster. Web server connector clustering provides load balancing and failover.
Object clustering
JRun provides load balancing and failover for requests to EJBs and services located on a JRun server that participates in a cluster.
Web server clustering
Macromedia ClusterCATS manages HTTP requests among web servers in a cluster.

The sections "Connector-based clustering" and in "Object clustering" describe additional considerations for load balancing and failover.

JRun server clusters

You use the JMC to define JRun server clusters. For more information on defining a cluster of JRun servers, see the JMC online Help.

Note:   Do not add the admin JRun server to a cluster.

When you start a JRun server that belongs to a cluster, the cluster manager uses multicast to register itself with all other nearby clustered JRun servers (that is, JRun servers in the same cluster and on the same subnet). You can also name specific cluster members with the cluster manager unicastPeer attribute in the jrun.xml file. Specifying a unicast peer lets you cluster JRun servers that do not run on the same subnet.

JRun lets you automatically deploy enterprise applications, web applications, EJBs, and JCA connector to all servers in the cluster. Thus, you can ensure a consistent image across all JRun servers in a cluster.

Session persistence in a clustered environment

JRun session persistence functionality ensures that user sessions for JSPs, servlets, and stateful session beans are maintained when a server shuts down. In a nonclustered environment, the sessions are restored the next time JRun starts. In a clustered environment, however, you want session information to be immediately available to other servers in the cluster. This section describes JRun session persistence options and how they apply to clustering.

Note:   When executing a stateful session bean or a web application that uses sessions, JRun uses session affinity to route requests to the appropriate server. JRun can handle sessions based on cookies (the default), URL parameters, and form variables.

To get the from your clustered environment, you must understand session management options and how JRun handles session management. For web applications, JRun persists sessions using one of the following mechanisms:

You configure file, JDBC, and custom session persistence through elements in the jrun-web.xml file, as follows:
Element
Description
session-config
Wraps the persistence-config element.
persistence-config
Wraps all persistence elements.
active
Indicates whether session persistence is enabled. Specify true or false.
persistence-type|persistence-class
Specifies persistence-type or persistence-class, as follows:
  • Persistence type must be file or jdbc.
  • Persistence-class specifies the fully qualified class name of your customized session persistence manager.
You cannot specify both persistence-type and persistence-class.
persistence-synchronized
Specifies whether session persistence writing are synchronized. Specify true or false. The default is true.
class-change-option
Specifies the action JRun takes when the classloader changes, as follows:
  • Reload Reloads all sessions.
  • Drop Destroys all sessions.
  • Ignore Uses the currently loaded sessions.
session-swapping
Specifies whether session swapping is enabled. Specify true or false. When session swapping is enabled, JRun maintains a fixed number of sessions in memory and saves the rest (oldest) in the persistence store (file, JDBC, or custom class).
session-swap-interval
Specifies the frequency with which JRun monitors session pool size and saves least-recently-used sessions to the persistence store. The default is 5 seconds.
session-max-resident
Specifies the maximum number of resident sessions. The default is 9999999. Specify a value of 0 to write all sessions to the persistence store.
When using ClusterCATS, you must use a JDBC persistence type for all servers in the cluster and set this value to 0.
init-param
Specifies initialization parameters for a session persistence mechanism. Use the following subelements:
  • param-name
  • param-value

The following sections provide examples of these elements.

Using file-based session persistence

File-based session persistence is the default. In most cases you do not change any settings. However, you can modify settings, such as such as session-swapping and session-swap-interval.

In addition, file-based session persistence takes the following init-param:

The following example shows file-based session persistence in the jrun-web.xml file: 

...

<session-config>
��<persistence-config>
����<active>true</active>
����<persistence-type>file</persistence-type>
����<persistence-synchronized>true</persistence-synchronized>
����<class-change-option>reload</class-change-option>
����<session-swapping>true</session-swapping>
����<session-swap-interval>5</session-swap-interval>
����<session-max-resident>500</session-max-resident>
��</persistence-config>
...

When using file-based session persistence, you can pass a path attribute as an init-param, which specifies the directory to which JRun writes session information.

For more information on these settings, see the online descriptor documentation accessed from the JRun online documentation home page.

Using JDBC session management

JDBC-based session management allows multiple JRun servers to share a persistence store.

To user JDBC-based session management:

  1. Define a database table that has a varchar column (at least 100 characters long) for the session ID and a BLOB column to contain the session data.
  2. In every JRun server in the cluster, define a JRun data source that points to the database containing the session table.
  3. Modify the web application's jrun-web.xml file, changing persistence-type to JDBC and specifying init-param elements for the following items:

The following example illustrates JDBC-based session persistence in the jrun-web.xml file: 

...

<session-config>
��<persistence-config>
����<active>true</active>
����<persistence-type>jdbc</persistence-type>
����<persistence-synchronized>true</persistence-synchronized>
����<class-change-option>reload</class-change-option>
����<session-swapping>true</session-swapping>
����<session-swap-interval>5</session-swap-interval>
����<session-max-resident>500</session-max-resident>
����<init-param>
������<param-name>JDBCConnection</param-name>
������<param-value>samples</param-value>
����</init-param>
����<init-param>
������<param-name>JDBCSessionTable</param-name>
������<param-value>sessions</param-value>
����</init-param>
����<init-param>
������<param-name>JDBCSessionIDColumn</param-name>
������<param-value>sessionid</param-value>
����</init-param>
����<init-param>
������<param-name>JDBCSessionDataColumn</param-name>
������<param-value>sessiondata</param-value>
����</init-param>
��</persistence-config>
...

For more information on these settings, see the online descriptor documentation accessed from the JRun online documentation home page.

Using session replication

To use session replication for web applications, update the session-config element in jrun-web.xml file for all web applications that use in-memory session management. To replicate to all servers in a cluster, specify replication-config elements, as follows: 

...

<replication-config>
��<active>true</active>
��<buddy-list>*</buddy-list>
</replication-config>
...

Tip:   To implement this change for all web applications in a JRun server, code the replication-config settings in the SERVER-INF/default-web.xml file.

To replicate to one or more specific servers in a cluster, specify replication-config elements, as follows: 

...

replication-config>
��<active>true</active>
��<buddy-list>jrunserver2</buddy-list>
��<buddy-list>jrunserver3</buddy-list>
��<buddy-list>jrunserver4</buddy-list>
</replication-config>
...

Tip:   You can specify * to replicate across all servers in the cluster.

Restart all JRun servers after making these changes.

Implementing a custom session storage manager

JRun 3.x let you persist session information to a database. JRun 4 replaces this functionality with an interface that you can implement to persist session information to a site-specific session store, which could be a database or some other destination.

  1. Create a Java file that implements jrun.servlet.session.SessionStorage.
    ...
public class DBMSSessionStorage implements SessionStorage
...
  2. Import packages required by your custom session storage manager, including the following required classes:
  3. Establish variables to contain init-param properties passed to the init method.
    String dataSource;
String table;
String idColumn;
String dataColumn;
  4. Initialize variables in the init method. For example a DBMS-based custom session storage manager might use the following initialization parameters:
    public void init(Properties props) throws Exception {
��dataSource = props.getProperty("dataSource");
��if (dataSource == null) {
����dataSource = "defaultDataSource";
��}

��table = props.getProperty("table");
��if (table == null) {
����table = "sessions";
��}

��idColumn = props.getProperty("idColumn");
��if (idColumn == null) {
����idColumn = "sessionid";
��}

��dataColumn = props.getProperty("dataColumn");
��if (dataColumn == null) {
����dataColumn = "sessioninfo";
��}
} // end init
  5. Code a store method, which stores a session in the custom persistence mechanism. The store method has the following signature:
    public void store(String id, InputStream in, int len) throws Exception
  6. Code a retrieve method, which access a session from the custom persistence mechanism. The retrieve method has the following signature:
    public InputStream retrieve(String id) throws Exception
  7. Code a remove method, which deletes a session from the custom persistence mechanism. The remove method has the following signature:
    public void remove(String id) throws Exception
  8. Code a destroy method, which performs any clean up required when shutting down the service. The destroy method has the following signature:
    public void destroy()

For complete examples, see the SERVER-INF/lib/jrun/samples/session directory in the samples server.

Previous Up Next

Comments


ben pinnick said on Oct 28, 2003 at 2:42 AM :
The <buddy-list> attribute is infact <buddy-name>

 

RSS feed | Send me an e-mail when comments are added to this page | Comment Report

Current page: http://livedocs.adobe.com/jrun/4/JRun_Administrators_Guide/clustering2.htm