:)

|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha
|Labourey
|Sent: Friday, November 09, 2001 7:48 PM
|To: Bill Burke; Jboss-Dev; jBoss-User Mailing List
|Subject: [JBoss-dev] ANN: Clustering support for Stateful Session Beans
|
|
|Hello,
|
|The JBoss clustering saga with Bill Burke and I continues.
|
|A first version of clustering for Stateful Session Beans (SFSB) is now
|available on the CVS main branch.
|
|Features:
|=========
|       - Sessions of each node are replicated "in-memory" to some 
|other nodes of
|the cluster
|       - Cluster is automagically subdivided in sub-clusters (i.e.
|sub-partitions),
|         which optimal size is user-definable.
|       - Sessions are replicated in these sub-partitions and not 
|in the whole
|cluster.
|         For a 2-nodes cluster, it does not change anything but 
|for a 10-nodes
|cluster,
|         it would have meant that each node had to support the session-load
|(memory,
|         synchro, ..) of the whole cluster i.e. of 10 nodes => 
|doesn't scale. But
|with
|         this scheme, each node only support the load of a few 
|other nodes (1 or 2
|ideally)
|       - When a node dies or starts, a new set of sub-partitions 
|is automatically
|         re-computed. The result intends to minimise the number of 
|nodes that need
|         to move in another sub-partition (i.e. state-transfer) and avoid
|singleton groups
|         (singletons are added to another sub-partition even if it 
|makes the
|sub-partition
|         become temporarily bigger than the user-defined optimal size)
|       - If state doesn't change after an invocation made on a 
|SFSB, its state is
|not replicated
|       - When a node join a sub-partition, the state is compressed 
|before being
|sent to it.
|
|
|Basic Setup:
|============
|As for any JBoss clustering feature, to use them you first need to copy
|jboss-all/cluster/etc/cluster-service.xml in your deploy directory.
|
|To identify a bean as clustered, just add a <clustered>True</clustered>
|element to your jboss.xml SFSB definition. Example:
|
|       <jboss>
|           <enterprise-beans>
|             <session>
|               <ejb-name>My_Clustered_SFSB</ejb-name>
|               <jndi-name>My_Clustered_SFSB</jndi-name>
|-->            <clustered>True</clustered>
|             </session>
|           </enterprise-beans>
|       </jboss>
|
|
|Implementation Details:
|=======================
|       - The in-memory state management is done thanks to a new 
|"service": a
|HASessionState
|       - The HASessionState uses the a HAPartition (the default one) to
|communicate with other nodes
|       - When the cluster composition changes, only one node 
|computes the new
|sub-partition topology
|         that will be shared between nodes.
|       - sub-partitions use a new, dynamically created, 
|HAPartition. Only nodes of
|a particular sub-partition
|         (for example 2 nodes out of 10) use the same HAPartition, 
|thus, in this
|case we
|         would have 1 "global" HAPartition shared by all nodes for general
|communication and
|         5 HAPartition, each used by two different nodes for their 
|session state
|in-memory replication. But
|         at the end, each node only has 2 HAPartition: the global 
|one and its
|dedicated.
|       - To make the link between the SFSB container and the HASessionState
|service, we use a new
|         PersistenceManager: StatefulHASessionPersistenceManager.
|       - A new interceptor 
|(StatefulHASessionSynchronisationInterceptor) is added
|to the
|         interceptor chain, just after the 
|StatefulSessionInstanceInterceptor. Its
|goal is to
|         call the PersistenceManager and ask it to synchronise the 
|state of the
|SFSB after any
|         remote interface method call or a SFSB creation 
|(home.create (...)). In
|the future,
|         we may add the possibility, in jboss.xml, to indicate 
|which methods
|change the state of the
|         bean and thus optimise many read-only calls. This feature 
|could also be
|very useful for EB.
|
|
|Detailed Configuration:
|=======================
|A HASessionState service is started this way:
|
|  <mbean code="org.jboss.ha.hasessionstate.server.HASessionStateService"
|name="JBOSS-SYSTEM:service=HASessionState">
|       <attribute name="JndiName">/HASessionState/Default</attribute>
|       <attribute name="SubPartitionProperties"> - not indicated, check
|JavaGroups.com documentation - </attribute>
|       <attribute name="MainHaPartitionName">DefaultPartition</attribute>
|       <attribute name="SubPartitionSize">2</attribute>
|       <attribute name="SubPartitionCreationWaitTime">5000</attribute>
|       <attribute name="BeanCleaningDelay">1800000</attribute>
|       <attribute
|name="TopologyComputerClassName">org.jboss.ha.hasessionstate.server
|.HASessio
|nStateTopologyComputerImpl</attribute>
|  </mbean>
|
|All attributes are optional (and thus can be omitted). Default values are
|indicated.
|
|Meaning:
|       - JndiName: JNDI name/path under which the HASessionState 
|will be made
|available
|       - SubPartitionProperties: JavaGroups property string used 
|when creating
|Sub-Partition
|       - MainHaPartitionName: name of the HAPartition used by all 
|nodes of the
|cluster
|       - SubPartitionSize: number of nodes per sub-partition. May 
|not be respected
|(i.e. bigger)
|         to avoid singleton groups.
|       - SubPartitionCreationWaitTime: When starting a new 
|sub-partition, a member
|start first to avoid singleton group
|         (JavaGroups needs to be extended to avoid this). This 
|value indicates how
|much miliseconds other slave nodes need
|         to wait before connecting to the group.
|       - BeanCleaningDelay: when bean state is no more used it is 
|cleaned after
|this delay. This is needed because
|         the cache may not know its existence if a node inherited 
|its presence
|from another node.
|       - TopologyComputerClassName: name of the class used to compute a new
|topology after a group composition change.
|
|
|A SFSB can contain some more tags in jboss.xml:
|
|       <jboss>
|               <enterprise-beans>
|                       <session>
|                               <ejb-name>My_Clustered_SFSB</ejb-name>
|                               <jndi-name>My_Clustered_SFSB</jndi-name>
|                               <clustered>True</clustered>
|                               <cluster-config>
|                                       
|<partition-name>Default</partition-name>
|                                       
|<home-load-balance-policy></home-load-balance-policy>
|                                       
|<bean-load-balance-policy></bean-load-balance-policy>
|                                       
|<session-state-manager-jndi-name></session-state-manager-jndi-name>
|                               </cluster-config>
|                       </session>
|               </enterprise-beans>
|       </jboss>
|
|Meaning:
|       - partition-name: Name of the HAPartition to be used for cluster
|communication
|       - home-load-balance-policy: name of the Java class to be 
|used as a policy
|for the home proxy (default: load-balance)
|       - bean-load-balance-policy: name of the Java class to be 
|used as a policy
|for the bean proxy (default: first-available)
|       - session-state-manager-jndi-name: JNDI name of the 
|HASessionState to be
|used by our PersistenceManager for in-memory
|         replicated session state.
|
|
|This is alpha code. It is really new code and need deep testing and
|improvement. Feedback is really welcome.
|
|Cheers,
|
|
|
|                                                       Sacha
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development

_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to