What does Nexaweb Clustering do?
You can cluster Nexaweb applications to run on multiple JVM instances and multiple machines to meet the load balancing and failover requirements of enterprise applications. The Nexaweb Server clustering support augments an application server's native clustering support and is not meant to replace it. The main features of Nexaweb clustering include:
...
If multiple value objects have a reference to the same object, when the values are deserialized on the remote side they will have their own copy of the shared object since cross-referencing is not detected.
The performance of the shared store depends on the number of messages that Nexaweb sends, the size of individual messages and network bandwidth. In addition to the messages that Nexaweb sends to maintain the state of the SharedStore objects, Nexaweb also uses messaging to backup session UI DOM, and attributes and registered XML documents and to keep them in sync when changes occur.
Here is an example of creating and using a SharedStore object:
SharedStore s = ServiceManager.getSharedStoreManager().getSharedStore( "MyStore" );
s.put( "key", "value" );
If a local ShareStore instance named "MyStore" does not exist, one will be created automatically. When events start propagating to the remote servers, as a result of modifying this local instance, if a SharedStore with the name "MyStore" does not exist on a remote server, it will be created there the moment the first event reaches the server.
...
All of the benefits of the MessagingService framework transparantly extend to the clustering environment. This means if client1 and client2 subscribe to a topic 'MyTopic', and it so happens that client1 is connected to the server1, while client2 is connected to the server2 where both server1 and server2 belong to the same cluster, both clients will receive messages published on "topic1" as long as the message is published by one of the servers belonging to the same cluster or any client connected to some server that belongs to the same cluster.
How to configure Nexaweb Clustering?
General Requirements
Before you setup a cluster of Nexaweb Servers, follow the processes and steps required to setup clustering for your specific application server. For example, if you want to cluster a Nexaweb application running in an IBM Websphere environment, configure your Websphere environment for normal Websphere clustering.
in addition, you must:
...
When running in a clustered environment, each application instance has an address that uniquely identifies it among other clustered application instances. Nexaweb uses the address as a messaging destination for inter-server communication. The address has the following format:
<domain>.<cluster>.<server>.<application>
Consider the following guidelines for configuring application addresses:
...
- Values for these elements cannot contain spaces or dots.
- Nexaweb recommends that you makes these values as short as possible, since the address is part of every message sent in the cluster.
<domain>MyDomain</domain>
The domain of your server's cluster.
...
In a production environment, set this element to some specific value.
<cluster>MyCluster</cluster>
The name of the cluster to which this server belongs.
...
Set this element to some specific value.
<server>MyServer1</server>
A unique identifier for this server + JVM instance.
Nexaweb recommends that you comment out the server element or completely remove it from your application's nexaweb-server.xml configuration file. This allows Nexaweb to generate a unique server name for every server instance in your cluster.
<application>MyApp</application>
Unique id for your application.
...
The AppNodeManager service manages application instance nodes that belong to the same application cluster. When part of a cluster, every application instance has an AppNode object that uniquely identifies the application instance.
AppNodeManager keeps track of the local AppNode object and all remote AppNodes that have the same domain, cluster and application name as the local AppNode. The collection of the AppNodes that the AppNodeManager keeps track of constitutes the current application cluster view.
The AppNodeManager detects cluster membership changes and notifies AppNodeListeners. When the local AppNode starts up, the AppNodeManager schedules a heartbeat task that periodically broadcasts a heartbeat message that serves as an indication to all remote nodes that this node is up and running. If clustering is disabled on this node, this manager is inactive.
The <app-node-manager/> element, a child of the <clustering/> element, contains the following settings:
<heartbeat-period>5 sec</heartbeat-period>
Specifies how often the heartbeat message is broadcast to the other nodes in the cluster. The AppNodeManager uses heartbeats to determine when nodes join or leave the cluster. The messages also contain metadata describing the server's current state. That information helps to balance available resources more evenly. The valid value is any time interval as described in nexaweb.xml.
<max-missed-heartbeats>10</max-missed-heartbeats>
The maximum number of heartbeats any node is allowed to miss before it is considered gone.
<cluster-synchronization-delay>10 sec</cluster-synchronization-delay>
The time used to sync up with the rest of the cluster nodes at startup.
<machine-id>Machine1</machine-id>
When multiple server instances are running on the same machine, it is important to guarantee that the backup copies originating on all of these instances are stored on server instances running on some other physical machine. You can accomplish that by setting the same machine ID for all instances running on the same machine. When selecting a backup node for local sessions, the backup selection algorithm will make sure that the backup node has a different machine ID from the one used by the local node. This helps to prevent the local session and its backup residing on the same physical machine. If the machine id is not specified, a globally unique ID is generated.
...
The <backup-assignment-manager/> element, a child of the <clustering/> element, contains the following settings:
<backup-selector class="some.package.SomeClass" />
Specifies the fully qualified name of a class that implements some specific algorithm for selecting the 'best' backup node out of the list of available backup nodes. The best backup node is based on some particular criteria. For example, the algorithm that specifies the 'best' node as the node that has the least number of sessions (local + backups).
<backup-session-task-period>1 min</backup-session-task-period>
Nexaweb assigns a backup node to a new session immediately upon creation of that session. However, occasionally, there are no available backup nodes at the time of a session's creation. Therefore, Nexaweb periodically runs a task to attempt to back up the local ServerSessions that haven't been assigned a backup. This setting specifies the task's period. The valid values for this setting include any time interval as described in nexaweb.xml.
<backup-verification-task-period>5 min</backup-verification-task-period>
Specifies the period for the task that periodically compares the local session with its backup copy to make sure the two are in sync. The session components that are out of sync (i.e. datasets, session attributes) are resent to the backup node at that time. The task's goal is to recover from failures that never got detected (i.e. a message got sent out, never made it to the destination, and neither the sending nor the receiving side detected the failure and no new messages were ever sent out). Note that this type of failure is not very likely and comparing the backup with the local session is rather expensive. So the period should be reasonably large. The valid values for this setting include any time interval as described in nexaweb.xml.
...
The BackupRepositoryManager service manages the backup repository. The backup repository contains the backup sessions stored on this node. If failover is disabled on this node, this manager is inactive. The <backup-repository-manager/> element, a child of the <clustering/> element, contain the following settings:
<backup-store class="some.package.SomeClass"/>
Specifies the backup repository implementation used to store backup sessions. Currently, Nexaweb supports only in memory backup store implementation.
<backup-cleanup-period>5 min</backup-cleanup-period>
Specifies the period for the task that examines the backup repository and attempts to clean up backups that are no longer needed. The cleanup task uses the following criteria for determing what to clean up: if the backup copy has not been modified in more than the original maximum inactive interval of the ServerSession's http session and the ServerSession (with the same id as the backup one) does not exist anywhere in the cluster.
...
The <backup-synchronization-manager/> element, a child of the <clustering/> element, contains the following settings:
<resend-task-period>30 sec</resend-task-period>
The period for the task that resends session components (datasets, ServerSession attributes, and so forth) to the respective backup nodes. The components resent are the ones that got out of sync. The valid value is any time interval as described in nexaweb.xml.
<request-task-period>30 sec</request-task-period>
The period for the task that requests session component resends from the nodes hosting the local sessions. The valid value is any time interval as described in nexaweb.xml.
...
Under the <messaging> element you can specify multiple <factory-implementation/> elements, one element per messaging factory implementation (Continuum, JMS and so on).
Under each <factory-implementation/> element you can specify multiple <factory-instance/> elements. Multiple instances provide additional flexibility when trying to fine tune your application's performance. You can compare them to having multiple communication pipes. When you configure multiple factory instances you need to further specify the type of traffic with which to use each instance. You do this in the Nexaweb server using keys. You can associate a single instance with any number of keys, however you can associate only one messaging factory instance to a specific key. When a Nexaweb Server component needs to use a messaging factory, it provides a key. If there are no factory instances associated with that key, the application creates and uses an instance of the default messaging factory. You can use the following element, a child of the <messaging/> element, to specify the default messaging factory:
<default-messaging-factory class="MessagingFactoryClassName" />
Nexaweb Server components use the following keys:
AppNode
DocumentEvents
SessionEvents
SessionAttributeEvents
BackupSyncMessages
RpcExecutor
MessagingService
SharedStore
When you configure your application with clustering and default messaging, the aplication uses Continuum - Nexaweb's own UDP based messaging implementation that can be configured to use either broadcast or multicast. Multicast is used by default. The application creates three factory instances of that factory, each using a separate multicast port. The keys above are spread over the 3 instances in the following way:
Instance 1 keys (heartbeat messages): AppNode
Instance 2 keys (backup events): DocumentEvents, SessionEvents, SessionAttributeEvents, BackupSyncMessages, RpcExecutor
...
The 'jmsConfigName' attribute specifies the name of a JMS configuration block used to configure the particular instance of the JMS messaging factory. Since JMS configuration is quite large nexaweb-server.xml has a separate section for it, which allows multiple factory instances to reuse the same configuration if desired. You can configure multiple instances of the JMS messaging factory using the same JMS configuration block, or different ones.
Each JMS configuration block is specified inside nexaweb.xml with a single <jms> element under the <server> element and is used to configure an instance(s) of the JMS messaging factory. Every <jms> element has a 'name' attribute which can be any string that uniquely identifies this JMS configuration section (for example, the following block would be used by the factory instance defined above:
<jms name="jms-config1"/>).
You can have multiple <jms> blocks in your nexaweb-server.xml (make sure to specify a unique name attribute for each of them).
Following is the description of the children of a JMS configuration element.
<jndi>
Nexaweb uses the Java Naming and Directory Interface (JNDI) to look up JMS specific objects; therefore, confirm that your application server supports JNDI. Following are the children of the <jndi> element.
<connection-factory-jndi-name>
The JNDI name for the JMS connection factory. This is the full name that will be used to lookup the connection factory object in the JNDI environment. For example, jms/NexawebConnectionFactory. Connection factories are usually configured through the administration console of your application server.
<destination-jndi-name>
The JNDI name for the destination used by the message producer and consumer for sending and receiving messages.
<initial-context-environment>
<param name="paramName" value="paramValue/>
</initial-context-environment>
Initial context JNDI environment. The parameters specified in this block will be passed in when creating the initial JNDI context.
<connection>
The following are the JMS Connection specific settings.
<client-id>SomeId</client-id>
If you want to use a durable subscription, each JMS client has to be associated with a unique client ID. Usually this ID is configured through the administration console. If your JMS provider does not have a way to set it administratively, the JMS API provides a method to do that. You should be aware however that the J2EE specification prohibits using this method and any J2EE compliant container will throw an IllegalStateException. Nexaweb will attempt to set the provided value as the client ID. If the value is not specified and the ID is not set, Nexaweb will generate a unique ID and attempt to set it as the client ID.
<session>
The following are the JMS Session specific settings.
<transacted>false</transacted>
Transacted session mode. The valid values are true | false. For more information see the JMS specification.
<acknowledge-mode>javax.jms.Session.AUTO_ACKNOWLEDGE </acknowledge-mode>
Session acknowledge mode. You can use the fully qualified way shown above or specify an integer value in the range allowed by the JMS API. For more information see the JMS specification.
<message-producer>
The following are the settings for the message producer.
<delivery-mode>javax.jms.DeliveryMode.NON_PERSISTENT</delivery-mode>
Delivery mode for the message producer. You can use the fully
qualified way shown above or specify an integer value in the range allowed by the JMS API.
<priority>javax.jms.Message.DEFAULT_PRIORITY</priority>
Priority for the message delivery. You can use the fully qualified way shown above or specify an integer value in the range allowed by the JMS API.
<time-to-live>jms.Message.DEFAULT_TIME_TO_LIVE</time-to-live>
Message time-to-live. You can use the fully qualified way shown above or specify a long value (number of milliseconds)
<disable-message-id>false</disable-message-id>
Whether message IDs are disabled for the JMS messages. Allowed values are: true | false
<disable-message-timestamp>false</disable-message-timestamp>
Whether message timestamps are disabled for the JMS messages. Allowed values are: true | false.
<subscriber>
The following are the settings for the message subscriber.
<durable>false</durable>
Whether this subscriber durable or not. The allowed values are: true | false. The default value is false.
<subscription-name>MySubscription</subscription-name>
The name for the durable subscription. This setting is only required if the subscriber is durable. Durable subscribers normally have to be configured through the JMS administration console. By default a non-durable subscriber is created.
...
The request timeout is used by all inter-server synchronous message exchanges. The element below is a child of the <messaging> element.
<request-timeout>15 sec</request-timeout>
The value for this parameter is any valid time interval as described in nexaweb.xml.
...
| Code Block |
|---|
<server> <clustering enabled="true" failover="true"> <domain>MyDomain</domain> <cluster>MyCluster</cluster> <application>MyApp</application> </clustering> <messaging> <factory-implementation class="com.nexaweb.server.messaging.jms.JMSMessagingFactory"> <factory-instance jmsConfigName="config1"> <keys> <key>DocumentEvents</key> <key>SessionAttributeEvents</key> <key>SessionEvents</key> <key>BackupSyncMessages</key> <key>RpcExecutor</key> <key>AppNode</key> <key>MessagingService</key> <key>SharedStore</key> </keys> </factory-instance> </factory-implementation> </messaging> <jms name="config1"> <jndi> <connection-factory-jndi-name>jms/NexawebConnectionFactory </connection-factory-jndi-name> <destination-jndi-name>jms/NexawebTopic</destination-jndi-name> </jndi> <session> <transacted>false</transacted> <acknowledge-mode>javax.jms.Session.AUTO_ACKNOWLEDGE </acknowledge-mode> </session> <message-producer> <delivery-mode>javax.jms.DeliveryMode.NON_PERSISTENT</delivery-mode> <priority>javax.jms.Message.DEFAULT_PRIORITY</priority> <time-to-live>javax.jms.Message.DEFAULT_TIME_TO_LIVE </time-to-live> <disable-message-id>false</disable-message-id> <disable-message-timestamp>false</disable-message-timestamp> </message-producer> </jms> </server> |
How to Verify and Test Nexaweb Clustering?
Nexaweb Services JSP page
Nexaweb provides a set of JSP pages that help monitor the health of your Nexaweb application by providing details about each service running within your application, the state of your local sessions, performance meter statistics and so on. The page that displays all Nexaweb Services details in use by your application is located under:
<app-context>/Nexaweb/Services/index.jsp
If clustering is enabled you should see AppNodeManager in the list of services. In addition, if failover is enabled you should also see the 3 backup/failover related services:
BackupAssignmentManager
BackupRepositoryManager
BackupSynchronizationManager
If you do not see the above services, that means that Nexaweb clustering and/or failover are not enabled in your application. Check the nexaweb-server.xml located under WEB-INF/ directory within your application to make sure clustering and failover are enabled as described above. If you do not have that file you will need to create one and add the necessary settings to your file.
You should also check the LicensingService details (available in the same JSP page) to make sure the license in use allows clustering.
Finally, if the license looks correct and you have nexaweb-server.xml with the right settings in the right place, make sure that the directory where you modified or added nexaweb-server.xml is in fact the one being used by your application server (i.e. if you have multiple environments set up it is easy to keep modifying files in one place but running a server that's using a different location).
...