Jboss自带均衡器的配置
将文件夹%jboss%\docs\examples\varia\loadbalancer\loadbalancer.sar拷贝到%jboss%\ server\all\deploy下，并且修改loadbalancer.sar\loadbalancer.sar\META-INF\jboss- service.xml，在<host>标签中类出所有节点，在<sticky-session>标签中指定是否使用粘性 session。配置完成。
该均衡器的缺点是负载能力相对不高，配置参数太少，比如无法指定不同节点的负载加权，所以后面都以mod_jk为例，不再讲解jboss自带的负载均衡器的内容。
负载均衡的配置基本完成，启动jboss，其中过程中会列出DefaultPatition中所有的节点：
run.bat -c all
2、session sticky配置
apache 应该会以粘性session的方式分发请求。部署一个应用测试一下，你会发现粘性session没有起作用。因为我们还没有给jboss配置jvm路由 ( jvmRoute)，apache就无法知道究竟哪些session是属于哪个节点的。我们继续往下：
修改server1机器上的jboss的配置文件：%jboss%\server\all\deploy\jbossweb-tomcat55.sar\ META-INF\ jboss-service.xml
在110行有：<attribute name="UseJK">false</attribute>，将它改为true。值得注意的是在这行标签上面有一段注释，要求你在server.xml中必须有：
Engine name="jboss.web" jmvRoute="Node1" defaultHost="localhost"
请注意这里有一个气死人不偿命的小bug，jboss的官方文档把 jvmRoute写成了jmvRoute，就是v和m两个字母的颠倒让我郁闷了三天，翻遍了jboss.com和theserverside.com。都是直接拷贝的错，吐血吐到脱水啊。
下面需要修改server1上的%jboss%\server\all\deploy\jbossweb-tomcat55.sar\ server.xml，在32行左右有：
<Engine name="jboss.web" defaultHost="localhost">
给它增加一个jvmRoute属性：
<Engine jvmRoute="server1" name="jboss.web" defaultHost="localhost">
请注意，jvmRoute的值必须和mod_jk中的节点名字正确对应，否则无法正确路由。Cluster中的所有节点都应该做相应的配置。
Jboss的配置完成了，下面需要在你的web应用中修改配置文件，让它支持集群。
在WEB-INF\web.xml中加入属性： <distributable/>
Ok，基于用户的cluster完成了，每个用户会绑定都某个节点上进行交互。这种绑定是如何完成的呢？原来apache把客户分发到节点后，该节点会在用户的session id后面加上此节点的路由名称，变成这个样子：
Efdfxxd98daja87daj76da2dka**,server1
有了这个标志，就能分辨该session属于哪个节点。
3、session replication配置
下面要做的是基于request的cluster，也就让各个节点之间互相复制session状态。有两种复制模式，同步与异步。使用同步的方式， jboss会把session复制的操作和对request的响应放到一个应用事务(application transaction)，session 复制完成后才去处理request。异步复制则发送session复制的消息后马上处理request，session复制则会稍有延迟。但是在多框架的 web页面中，这样的集群方式会有问题。由于frame在同一时间发出多个request，会造成一些混乱，这也是采用基于用户的集群方式的原因之一。
JBoss 4.0.2 中采用了Jboss cache来实现session复制，实际上就是一个分布式缓存，由于session id中包含了jvm route，所以能够分辨session属于哪个节点。Session的更新类似于hibernate中的乐观锁，有了更新之后就让session的版本号增加，其他节点通过对比版本号来决定是否同步session状态。
配置session replication首先需要编辑
%jboss% server\all\deploy\jbossweb-tomcat55.sar\META-INF\ jboss-service.xml，88行左右有：
<attribute name="SnapshotMode">instant</attribute>
这就是刚才提到的复制模式，instant为立即复制，如果设为interval 那么系统会在延迟一段时间再进行复制，时间长度在< attribute name="SnapshotInterval">2000</attribute>中指定，单位是毫秒。
单独配置这一个地方还不够，在%jboss% server\all\deploy\ tc5-cluster-service.xml中有：
<attribute name="CacheMode">REPL_ASYNC</attribute>
这里才真正决定复制是同步的还是异步的，可以指定为REPL_ASYNC(异步)或者REPL_SYNC(同步)。
在这个文件下面一点，还有一个config标签，里面指定了各个节点在进行session复制的时候如何通信，有udp和tcp两种可选，如果使用udp方式，那么应该将udp的lookback属性指定为true，因为windows上有一个叫做media sense的东西会影响 udp multicast。注意如果你不了解multi address的ip规则，请不要随便修改mcast_addr的值。如果采用tcp方式的话，应该指定bind_addr的值为本机ip，并且在TCPPING标签的initial_hosts属性中列出所有节点，格式是”机器名[端口号]”，比如在我们的例子中，就应该这样配置tcp(以其中一个节点为例)：
<config><TCP bind_addr="172.16.0.116" start_port="7810" loopback="true"/><TCPPING initial_hosts="172.16.0.116[7810],172.16.32.88[7810]" port_range="3" timeout="3500"num_initial_members="3" up_thread="true" down_thread="true"/><MERGE2 min_interval="5000" max_interval="10000"/><FD shun="true" timeout="2500" max_tries="5" up_thread="true" down_thread="true" /><VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false" /> <pbcast.NAKACK down_thread="true" up_thread="true" gc_lag="100" retransmit_timeout="3000"/> <pbcast.STABLE desired_avg_gossip="20000" down_thread="false" up_thread="false" /> <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="false"print_local_addr="true" down_thread="true" up_thread="true"/><pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/></config>
JBoss的clustering版主建议尽量使用udp。不过在Sobey内部，建议使用tcp方式，经测试可能有不明物体在影响udp通信，导致Timeout异常。
在%jboss%\ server\all\deploy\ cluster-service.xml中也有关于udp和tcp的配置信息，在4.0以前版本的jboss中，会以这个文件为主配置，4.0以后都以tc5-cluster-service.xml为主配置。
Jboss的配置完成了，最后需要在web应用中增加配置信息，控制session复制的粒度。在WEB-INF\ jboss-web.xml中增加以下内容：
<replication-config> <replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger> <replication-granularity>SESSION</replication-granularity> </replication-config>
其中replication-trigger是指定哪些操作引发session的版本更新，它的取值有：
SET_AND_GET SET_AND_NON_PRIMITIVE_GETSET
replication-granularity是复制粒度，可以取session或attribute。如果取为attribute有可能导致复制失败，这是目前版本的jboss cache的一个bug，等待修正。
部署项目，测试，如果配置没有问题，可以在%jboss%\0server\all\log\server.log中发现类似于这样的信息：
DEBUG [org.jboss.web.tomcat.tc5.session.JBossCacheManager] check to see if needs to store and replicate session with id Im9-qpuaXppMS+xXwE3M+Q**.server1 DEBUG [org.jboss.web.tomcat.tc5.session.ClusteredSession] processSessionRepl(): session is dirty. Will increment version from: 20 and replicate.
Session replication配置的成功率比较低，情况也很复杂，请仔细操作。
将文件夹%jboss%\docs\examples\varia\loadbalancer\loadbalancer.sar拷贝到%jboss%\ server\all\deploy下，并且修改loadbalancer.sar\loadbalancer.sar\META-INF\jboss- service.xml，在<host>标签中类出所有节点，在<sticky-session>标签中指定是否使用粘性 session。配置完成。
该均衡器的缺点是负载能力相对不高，配置参数太少，比如无法指定不同节点的负载加权，所以后面都以mod_jk为例，不再讲解jboss自带的负载均衡器的内容。
负载均衡的配置基本完成，启动jboss，其中过程中会列出DefaultPatition中所有的节点：
run.bat -c all
2、session sticky配置
apache 应该会以粘性session的方式分发请求。部署一个应用测试一下，你会发现粘性session没有起作用。因为我们还没有给jboss配置jvm路由 ( jvmRoute)，apache就无法知道究竟哪些session是属于哪个节点的。我们继续往下：
修改server1机器上的jboss的配置文件：%jboss%\server\all\deploy\jbossweb-tomcat55.sar\ META-INF\ jboss-service.xml
在110行有：<attribute name="UseJK">false</attribute>，将它改为true。值得注意的是在这行标签上面有一段注释，要求你在server.xml中必须有：
Engine name="jboss.web" jmvRoute="Node1" defaultHost="localhost"
请注意这里有一个气死人不偿命的小bug，jboss的官方文档把 jvmRoute写成了jmvRoute，就是v和m两个字母的颠倒让我郁闷了三天，翻遍了jboss.com和theserverside.com。都是直接拷贝的错，吐血吐到脱水啊。
下面需要修改server1上的%jboss%\server\all\deploy\jbossweb-tomcat55.sar\ server.xml，在32行左右有：
<Engine name="jboss.web" defaultHost="localhost">
给它增加一个jvmRoute属性：
<Engine jvmRoute="server1" name="jboss.web" defaultHost="localhost">
请注意，jvmRoute的值必须和mod_jk中的节点名字正确对应，否则无法正确路由。Cluster中的所有节点都应该做相应的配置。
Jboss的配置完成了，下面需要在你的web应用中修改配置文件，让它支持集群。
在WEB-INF\web.xml中加入属性： <distributable/>
Ok，基于用户的cluster完成了，每个用户会绑定都某个节点上进行交互。这种绑定是如何完成的呢？原来apache把客户分发到节点后，该节点会在用户的session id后面加上此节点的路由名称，变成这个样子：
Efdfxxd98daja87daj76da2dka**,server1
有了这个标志，就能分辨该session属于哪个节点。
3、session replication配置
下面要做的是基于request的cluster，也就让各个节点之间互相复制session状态。有两种复制模式，同步与异步。使用同步的方式， jboss会把session复制的操作和对request的响应放到一个应用事务(application transaction)，session 复制完成后才去处理request。异步复制则发送session复制的消息后马上处理request，session复制则会稍有延迟。但是在多框架的 web页面中，这样的集群方式会有问题。由于frame在同一时间发出多个request，会造成一些混乱，这也是采用基于用户的集群方式的原因之一。
JBoss 4.0.2 中采用了Jboss cache来实现session复制，实际上就是一个分布式缓存，由于session id中包含了jvm route，所以能够分辨session属于哪个节点。Session的更新类似于hibernate中的乐观锁，有了更新之后就让session的版本号增加，其他节点通过对比版本号来决定是否同步session状态。
配置session replication首先需要编辑
%jboss% server\all\deploy\jbossweb-tomcat55.sar\META-INF\ jboss-service.xml，88行左右有：
<attribute name="SnapshotMode">instant</attribute>
这就是刚才提到的复制模式，instant为立即复制，如果设为interval 那么系统会在延迟一段时间再进行复制，时间长度在< attribute name="SnapshotInterval">2000</attribute>中指定，单位是毫秒。
单独配置这一个地方还不够，在%jboss% server\all\deploy\ tc5-cluster-service.xml中有：
<attribute name="CacheMode">REPL_ASYNC</attribute>
这里才真正决定复制是同步的还是异步的，可以指定为REPL_ASYNC(异步)或者REPL_SYNC(同步)。
在这个文件下面一点，还有一个config标签，里面指定了各个节点在进行session复制的时候如何通信，有udp和tcp两种可选，如果使用udp方式，那么应该将udp的lookback属性指定为true，因为windows上有一个叫做media sense的东西会影响 udp multicast。注意如果你不了解multi address的ip规则，请不要随便修改mcast_addr的值。如果采用tcp方式的话，应该指定bind_addr的值为本机ip，并且在TCPPING标签的initial_hosts属性中列出所有节点，格式是”机器名[端口号]”，比如在我们的例子中，就应该这样配置tcp(以其中一个节点为例)：
<config><TCP bind_addr="172.16.0.116" start_port="7810" loopback="true"/><TCPPING initial_hosts="172.16.0.116[7810],172.16.32.88[7810]" port_range="3" timeout="3500"num_initial_members="3" up_thread="true" down_thread="true"/><MERGE2 min_interval="5000" max_interval="10000"/><FD shun="true" timeout="2500" max_tries="5" up_thread="true" down_thread="true" /><VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false" /> <pbcast.NAKACK down_thread="true" up_thread="true" gc_lag="100" retransmit_timeout="3000"/> <pbcast.STABLE desired_avg_gossip="20000" down_thread="false" up_thread="false" /> <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="false"print_local_addr="true" down_thread="true" up_thread="true"/><pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/></config>
JBoss的clustering版主建议尽量使用udp。不过在Sobey内部，建议使用tcp方式，经测试可能有不明物体在影响udp通信，导致Timeout异常。
在%jboss%\ server\all\deploy\ cluster-service.xml中也有关于udp和tcp的配置信息，在4.0以前版本的jboss中，会以这个文件为主配置，4.0以后都以tc5-cluster-service.xml为主配置。
Jboss的配置完成了，最后需要在web应用中增加配置信息，控制session复制的粒度。在WEB-INF\ jboss-web.xml中增加以下内容：
<replication-config> <replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger> <replication-granularity>SESSION</replication-granularity> </replication-config>
其中replication-trigger是指定哪些操作引发session的版本更新，它的取值有：
SET_AND_GET SET_AND_NON_PRIMITIVE_GETSET
replication-granularity是复制粒度，可以取session或attribute。如果取为attribute有可能导致复制失败，这是目前版本的jboss cache的一个bug，等待修正。
部署项目，测试，如果配置没有问题，可以在%jboss%\0server\all\log\server.log中发现类似于这样的信息：
DEBUG [org.jboss.web.tomcat.tc5.session.JBossCacheManager] check to see if needs to store and replicate session with id Im9-qpuaXppMS+xXwE3M+Q**.server1 DEBUG [org.jboss.web.tomcat.tc5.session.ClusteredSession] processSessionRepl(): session is dirty. Will increment version from: 20 and replicate.
Session replication配置的成功率比较低，情况也很复杂，请仔细操作。