| JRun Administrator's Guide |
|
|
Clustering |
|
| JRun Administrator's Guide |
|
|
Clustering |
|
The JRun clustering architecture is controlled by the cluster manager, which runs on each JRun server for which you enabled clustering. At server startup time, clusterable services use the JINI lookup service to register themselves with each cluster manager. in the cluster. This enables each cluster manager to discover all clusterable services in the cluster and also enables each clusterable service to discover its peers in the cluster. The following figure shows cluster managers and clusterable services:
JRun provides the following clusterable services:
| Service |
Description |
|---|---|
| JNDI context manager |
When a client requests a clusterable object through a JNDI lookup, JRun returns a context manager that knows about all servers in the cluster. This means that these resources are consistently available through the failover that is automatically in effect for clustered JRun servers. It also means that JRun balances load. |
| RMI broker |
The RMI transport implementation for all remote access in JRun. |
| Session replication |
When using session replication for web applications, the session replication service uses clustering to synchronize state with a buddy server in the cluster. For more information, see "Using session replication". |
Note: Cluster names must be unique and JRun servers in a cluster also must have unique names. For example, if multiple developers on the same subnet use the default cluster name when defining a cluster that contains the default JRun server, there will be problems (random access to JNDI).
JRun clustering includes the following restrictions:
clusterEnabled attribute to true for the DefaultDomain service for all servers in the cluster.After you define a cluster in the JMC, object clustering operates transparently to most users. However, there are clustering considerations for certain types of developers, as follows:
The following sections explain these topics.
When a client looks up an EJB through JNDI, JRun returns a context manager that knows about all servers in the cluster. This means that these resources are consistently available through the failover that is automatically in effect for clustered JRun servers. It also means that JRun automatically balances load across the cluster using different load- balancing algorithms, as follows:
The following figure shows EJB clustering:
If a JRun server goes offline during a call to an EJB method, the client stub automatically reroutes the request to another server in the cluster. In addition, object clustering provides replication for stateful session beans by automatically passivating state to the buddy server in the cluster.
When you create a cluster in the JMC, EJB clustering is enabled automatically. To disable clustering for EJBs, specify false for the cluster-home and cluster-object elements in the jrun-ejb-jar.xml file. Local EJBs are not clusterable.
For more information on defining a cluster, see the JMC online Help.
JRun JMS supports clustering through modifications to descriptor files for the JMS services in the clustered JRun servers.
JRunMQAdapter service on all servers but one.
AdapterType for JMSServiceWrapper to remote.AdapterServerName attribute to JMSServiceWrapper. Set it to the name of the server for which the JRunMQAdapter service is still enabled.JMSUrl attribute for JMSServiceWrapper to the servername:jndiportof the target server. You can determine this setting by looking at the java.naming.provider.url property in the target server's SERVER-INF/jndi.properties file.JMSContextFactoryName for JMSServiceWrapper to jrun.naming.JRunContextFactory. This setting matches the java.naming.factory.initial property in the target server's SERVER-INF/jndi.properties file.The following example shows changes made to a jrun.xml file to enable JMS clustering for all non-target JRun servers:
...
<service class="jrun.jms.JRunJMS" name="JRunJMS">
...
<!-- ======================================================================= -->
<!-- This service starts the JMS provider. (JRun built-in) -->
<!-- ======================================================================= -->
<!--
<service class="jrun.jms.adapter.JRunMQAdapter" name="JMSAdapter">
<attribute name="ConfigFileName">jrun-jms.xml</attribute>
<attribute name="bindToJNDI">true</attribute>
</service>
-->
<!-- ==================================================================== -->
<!-- This service provides JMS access for J2EE clients (JRun built-in) -->
<!-- ==================================================================== -->
<service class="jrun.jms.wrapper.JRunMQServiceWrapper" name="JMSServiceWrapper">
<attribute name="bindToJNDI">true</attribute>
<attribute name="DefaultQCFName">QueueConnectionFactory</attribute>
<attribute name="DefaultTCFName">TopicConnectionFactory</attribute>
<attribute name="DefaultTransport">RMI</attribute>
<attribute name="JMSUrl">localhost:2918</attribute>
<attribute name="JMSContextFactoryName">jrun.naming.JRunContextFactory</attribute>
<!-- AdapterType indicates whether wrapper should use remote or local
adapter -->
<attribute name="AdapterType">remote</attribute>
<attribute name="AdapterServerName">fresca</attribute>
</service>
Because JNDI is a clusterable service, any service whose jrun-xml.file definition sets the bindToJNDI attribute to true is also clustered. For example, assume that two servers in a cluster both define a JDBC data source named compass. If a client application accesses the data source through an InitialContext.lookup for compass, the javax.sql.DataSource that is returned could be from either of the JRun servers in the cluster.
However, in addition to clustering the resources deployed on a JRun server, the services can also be clusterable. JRun saves references to services in multiple locations in the JNDI tree. Clustered entries are in jrun:service/servicename, entries for the local JRun server are in jrun:service/servername/servicename. For more information on JNDI in JRun, see Chapter 8, "JNDI Considerations".
The following sample code accesses the JRun LoggerService and can receive a reference to any JRun server in the cluster:
...
// To run this example, you must set the bindToJNDI attribute to
// true in the LoggerService (jrun.xml file).
import java.util.Properties;
import javax.naming.InitialContext;
import javax.naming.Context;
import jrunx.logger.LoggerService;
...
try {
Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, "jrun.naming.JRunContextFactory");
p.put(Context.PROVIDER_URL, "localhost:2918");
InitialContext ctx = new InitialContext(p);
LoggerService ls = (LoggerService) ctx.lookup("jrun:service/LoggerService");
ls.logInfo("Message logged using LoggerService");
} // end try
catch (Exception e) {
System.out.println(e);
throw new Exception(e);
}
...
To ensure that a JNDI lookup returns a reference to a specific JRun server, include the server name in the string passed to the lookup method, as the following example shows:
...
LoggerService ls = (LoggerService) ctx.lookup("jrun:service/samples/LoggerService");
...
Note: To access services through JNDI, the service must have the bindToJNDI attribute set to true. For more information, see "Attributes common to all services".
|
|
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/clustering4.htm
Comments
No screen name said on Apr 8, 2004 at 7:04 AM :