Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Cluster Configuration 

 

Section
Column

 supports clustered form servers for both high availability, load balancing and fault tolerance. The software can be installed and configured either as a stand-alone single form server or as a cluster of form servers behind an a load balancer.

Info

NOTE that only certain version include clustering. Please refer to the Release Notes for details.

 

A Form Server Cluster is instrumental in heavy load scenarios where a single form server cannot handle the load alone. Clustering also enables fault tolerance should one node fail for either design time or use mode forms. If one form server is shutdown the form instances automatically get transferred to another running form server node.

 supports clusters running under either Apache web servers or Oracle Web Logic servers. This chapter details how to enable a  cluster running under an Apache web server.

Column
width300px

On this page: 

Table of Contents
maxLevel2

 

...

Configure Tomcat Form Servers

The firsts first step is to install the  software on each machine that will become a node in your cluster. In order to provide scalability and fault tolerance it's most likely that each form server node will run on a separate physical machines - a distributed cluster. However it is possible to install two nodes on the same physical machine. This documentation covers both scenarios.

...

  1. Follow the steps documented under Downloading & Installing to install a copy of  on each machine.
  2. Edit <frevvo-home>/frevvo/tomcat/config/server.xmlin each installation to:
    1. Setup the AJP jvmRoute
    2. Uncomment the <Cluster> element
    3. Change the value of the channelSendOptions="8"> in the cluster section to 6. This makes sure that session replication is synchronous and messages are not received out of order.
  3. Edit <frevvo-home>/frevvo/tomcat/bin/setenv.bat on windows or setenv.sh on linux to add cluster setenv parameters.
  4. Edit <frevvo-home/frevvo/tomcat/conf/Catalina/localhost/frevvo.xml 
    1. Uncomment the <Manager> element for DeltaManager.
    2. Ensure that the form server's database configured in frevvo.xml is the same database used for ALL cluster nodes.

...

Search <frevvo-home>/frevvo/tomcat/config/server.xml to locate the <Cluster> element. Uncomment the <Cluster> element. Before you your edits the server.xml contains the <!-- characters before and --> characters after the many lines that constitute the <Cluster> element:

Code Block
<!-- 
   <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
                 channelSendOptions="86">
          <Channel className="org.apache.catalina.tribes.group.GroupChannel">
            <Membership className="org.apache.catalina.tribes.membership.McastService"
                        address="228.0.0.4"
                        port="55555"
                        frequency="500"
                        dropTime="3000"/>
            <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                      address="auto"
                      port="4000"
                      autoBind="100"
                      selectorTimeout="5000"
                      maxThreads="6"/>
            <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
              <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
            </Sender>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
          </Channel>
          <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
                 filter=""/>
          <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
          <ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
          <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
      </Cluster>
 -->

...

Blah Blah Blah... Work in Progress!!!!!

Special Considerations

Upload Control

The upload control is not currently fault tolerant. Uploaded file attachments are only stored with the node that processed the upload. If the node that is processing your form instance shuts down, all attachments are lost. The user will notice this only If the user refreshes the form or tries to add/delete another attachment. In this case the upload control is refreshed and the current state of all prior attachments having been removed becomes visible. If the user does not refresh the form or add/delete another attachment the form will continue to show the lost attachments. However when the form is submitted they will not be part of the submission. This out of sync behavior will be addressed in a future software update.

...

  • retry (default 60secs) - "Connection pool worker retry timeout in seconds. If the connection pool worker to the backend server is in the error state, Apache will not forward any requests to that server until the timeout expires. This enables to shut down the backend server for maintenance, and bring it back online later. A value of 0 means always retry workers in an error state with no timeout."
  • ping (not set by default)- "Ping property tells the web server to send a CPING request on ajp13 connection before forwarding a request. The parameter is the delay in seconds to wait for the CPONG reply. This features feature has been added to avoid problem problems with hung and busy Tomcat 's and require ajp13 ping/pong support which has been implemented on Tomcat 3.3.2+, 4.1.28+ and 5.0.13+. This will increase the network traffic during the normal operation which could be an issue, but it will lower the traffic in case some of the cluster nodes are down or busy. Currently this has an effect only for AJP. By adding a postfix of ms the delay can be also set in milliseconds."

...

If a form is in use when a designer edits that form to add/remove/modify fields, as usual this creates a new form version but the form currently in use remains at the original version. The form user is not disrupted and continues to use the current form instance until the submit the formthe form is submitted. However if the cluster node running this form instance fails, when the form instance is reinstantiated on another cluster node it gets updated to the new form version. The user will see a session expiration error message.

...