网上类似文章很多，用了MX4J后，发现管理界面做的不是特别好，个人感觉吧，换成了MC4J.

1.MC4J的下载地址：http://mc4j.sourceforge.net MC4J的最新版本好象不能下载，只能下载MC4J Console 1.2b9了。

这部分介绍内容，我直接Copy过来的。

   Tomcat 5.5.9(我用的是tomcat5.5.27解压版)以上采用Java管理扩展（JMX）管理beans（managed beans）技术实现了对servlet容器的管理，其中包括监测所有的集群（cluster）元素和session复制情况。
   而J2SE5.0在监测和管理方面的支持很全面，拥有对Java平台及运行于其上的应用进行远程监测能力。J2SE 5.0中包含了Java管理扩展（JMX）远程监测技术，这是对JVM监控能力的一个新的补充。
   有了最新版的Tomcat和J2SE 5.0的JMX技术，我们就可以通过JMX来使用servlet容器的属性和方法，同时减少与JMX相关的复杂编码。我在本文中将简单介绍如何在启动Tomcat servlet容器时启用远程JMX监测。

一、JMX 客户端

   JMX客户端是一个用来连接JMX代理（运行在本地或远程）的图形化用户界面（客户机/服务器或瘦客户端）。理想的JMX客户端具备以下特点，能够有效地监测应用服务器而不为其带来额外的负担：
---对系统和网络资源的低占用
---能保持系统的稳定和性能
---少量的或无需特别设置（即使需要设置，也是简单明了而不是编程方式的）
---可提供良好的报告

   J2SE 5.0附带了一个称为Jconsole的JMX客户端工具，可用来查看JVM运行时的详细情况。Tomcat的安装中包含了一个叫做JMXProxyServlet的JMX servlet，可用来查看、更新Tomcat MBeans的属性。它是一个能查看、操作运行于Tomcat容器中的MBeans的轻量级代理，通过与命令行脚本共同作用来监测和改变Tomcat的内部运行。

除了这两个工具，还有几个第三方开源JMX客户端应用程序：
---XMOJO
---jManage
---MX4J
---Spring JMX
---JMX-HTML适配器
---MC4J JMX控制台

上面我只试过MX4J和MC4J这两种，总体感觉MC4J操作起来容易些。

设定JAVA_HOME/lib/management目录下名为management.properties的属性文件，将下面的几行copy到management.properties文件中去。
com.sun.management.jmxremote.port=9393
com.sun.management.jmxremote.ssl=false
com.sun.management.jmxremote.authenticate=true
com.sun.management.jmxremote.password.file=JAVA_HOME/jre/lib/management/jmxremote.password 
com.sun.management.jmxremote.access.file=JAVA_HOME/jre/lib/management/jmxremote.access

接下来在JAVA_HOME/lib/management目录下建立密码文件直接用密码模板文件(文件名jmxremote.password.template)拷贝出一个名为jmxremote.password的新文件,将密码文件的文件权限设置为只有你能读写
将monitorRole 和controlRole前面的注释去掉就可以了。

   为了启动Tomcat服务器时启用远程JMX监测，要修改装有tomcat的机器上的(catalina.bat 或catalina.sh)做如下修改：

set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote.port=9393

将原来的JAVA_OPTS那行注释掉，用上面这行替换就行了。启动tomcat，可以看到tomcat正常启动了。

  安装MC4J，直接setup.exe，默认安装就行了。

  因为我的环境是MC4J的安装机器和2个tomcat都在不同的机器上，所以在MC4J管理界面中注册远程server的时候，需要改变点东西。在注册远程server的时候，下面的信息需要填写：

Name  tomcat5.5 
Initial Context Factory  com.sun.jndi.rmi.registry.RegistryContextFactory 
Servet URL  service:jmx:rmi:///jndi/rmi://localhost:9393/jmxrmi 
Principle  monitorRole 
Credentials  QED

对于ServetURL，如果tomcat在远程，请将localhost换成它的IP地址。这里需要注意的是从MC4J官方的文档得知，如果需要注册远程的tomcat，你需要在MC4J本机保持一份tomcat跟远程主机上的tomcat一样的就可以了。对于其它web server同理。在注册的时候，MC4J需要你指定tomcat路径，指定过后，他会找三个文件。catalina.jar、catalina-cluster.jar和 catalina-optional.jar文件(位于%CATALINA_HOME%\server\lib\目录下)

注册成功后，你可以远程监控tomcat集群，对其进行管理并且了解session复制的情况。

为了做性能测试，因为测试的需求，用户数比较多，为了不在tomcat上形成瓶颈。做了个apache+tomcat集群，先做了个试验，确保集群可行。结果发现只能在两个tomcat之间进行负载平衡，不能进行session复制，查了半天原因，每个tomcat启动的时候都会提示:

信息: Manager [/test]: skipping state transfer. No members active in cluster group.

想来想去，配置都是好的，为什么组播不能成功呢，刚开始也没有想到这方面。总觉的是配置哪方面有问题，但是配置实在是很简单，应该不会有什么问题。检查了下网络。发现，因为两个tomcat server之间是通过多个网络设备(switch/智能HUB)进行连接的，会不会是这方面的原因导致组播不行呢？换了网络环境，立刻可以了，晕倒！在这里顺便把组播的原理贴出来再温习下。很多年不搞网络方面的东西了，集群的东西在后面整理下再贴上来。

单播、多播和广播单播”（Unicast）、“多播”（Multicast）和“广播”（Broadcast）这三个术语都是用来描述网络节点之间通讯方式的术语。那么这些术语究竟是什么意思？区别何在？
1.单播：网络节点之间的通信就好像是人们之间的对话一样。如果一个人对另外一个人说话，那么用网络技术的术语来描述就是“单播”，此时信息的接收和传递只在两个节点之间进行。单播在网络中得到了广泛的应用，网络上绝大部分的数据都是以单播的形式传输的，只是一般网络用户不知道而已。例如，你在收发电子邮件、浏览网页时，必须与邮件服务器、Web服务器建立连接，此时使用的就是单播数据传输方式。但是通常使用“点对点通信”（Point to Point）代替“单播”，因为“单播”一般与“多播”和“广播”相对应使用。
2.多播：“多播”也可以称为“组播”，在网络技术的应用并不是很多，网上视频会议、网上视频点播特别适合采用多播方式。因为如果采用单播方式，逐个节点传输，有多少个目标节点，就会有多少次传送过程，这种方式显然效率极低，是不可取的；如果采用不区分目标、全部发送的广播方式，虽然一次可以传送完数据，但是显然达不到区分特定数据接收对象的目的。采用多播方式，既可以实现一次传送所有目标节点的数据，也可以达到只对特定对象传送数据的目的。 　　IP网络的多播一般通过多播IP地址来实现。多播IP地址就是D类IP地址，即224.0.0.0至239.255.255.255之间的IP地址。Windows 2000中的DHCP管理器支持多播IP地址的自动分配。
3.广播：“广播”在网络中的应用较多，如客户机通过DHCP自动获得IP地址的过程就是通过广播来实现的。但是同单播和多播相比，广播几乎占用了子网内网络的所有带宽。拿开会打一个比方吧，在会场上只能有一个人发言，想象一下如果所有的人同时都用麦克风发言，那会场上就会乱成一锅粥。集线器由于其工作原理决定了不可能过滤广播风暴，一般的交换机也没有这一功能，不过现在有的网络交换机（如全向的QS系列交换机）也有过滤广播风暴功能了，路由器本身就有隔离广播风暴的作用。 　　广播风暴不能完全杜绝，但是只能在同一子网内传播，就好像喇叭的声音只能在同一会场内传播一样，因此在由几百台甚至上千台电脑构成的大中型局域网中，一般进行子网划分，就像将一个大厅用墙壁隔离成许多小厅一样，以达到隔离广播风暴的目的。 　　在IP网络中，广播地址用IP地址“255.255.255.255”来表示，这个IP地址代表同一子网内所有的IP地址。
当前的网络中有三种通讯模式：单播、广播、组播(多播)，其中的组播出现时间最晚但同时具备单播和广播的优点，最具有发展前景。
一、单播：
主机之间“一对一”的通讯模式，网络中的交换机和路由器对数据只进行转发不进行复制。如果10个客户机需要相同的数据，则服务器需要逐一传送，重复10次相同的工作。但由于其能够针对每个客户的及时响应，所以现在的网页浏览全部都是采用IP单播协议。网络中的路由器和交换机根据其目标地址选择传输路径，将IP单播数据传送到其指定的目的地。
单播的优点：
1. 服务器及时响应客户机的请求
2. 服务器针对每个客户不通的请求发送不通的数据，容易实现个性化服务。
单播的缺点：
1. 服务器针对每个客户机发送数据流，服务器流量＝客户机数量×客户机流量；在客户数量大、每个客户机流量大的流媒体应用中服务器不堪重负。
2. 现有的网络带宽是金字塔结构，城际省际主干带宽仅仅相当于其所有用户带宽之和的5％。如果全部使用单播协议，将造成网络主干不堪重负。现在的P2P应用就已经使主干经常阻塞，只要有5％的客户在全速使用网络，其他人就不要玩了。而将主干扩展20倍几乎是不可能。
二、 广播：
主机之间“一对所有”的通讯模式，网络对其中每一台主机发出的信号都进行无条件复制并转发，所有主机都可以接收到所有信息（不管你是否需要），由于其不用路径选择，所以其网络成本可以很低廉。有线电视网就是典型的广播型网络，我们的电视机实际上是接受到所有频道的信号，但只将一个频道的信号还原成画面。在数据网络中也允许广播的存在，但其被限制在二层交换机的局域网范围内，禁止广播数据穿过路由器，防止广播数据影响大面积的主机。
广播的优点：
1. 网络设备简单，维护简单，布网成本低廉
2. 由于服务器不用向每个客户机单独发送数据，所以服务器流量负载极低。
广播的缺点：
1.无法针对每个客户的要求和时间及时提供个性化服务。
2. 网络允许服务器提供数据的带宽有限，客户端的最大带宽＝服务总带宽。例如有线电视的客户端的线路支持100个频道（如果采用数字压缩技术，理论上可以提供500个频道），即使服务商有更大的财力配置更多的发送设备、改成光纤主干，也无法超过此极限。也就是说无法向众多客户提供更多样化、更加个性化的服务。
3. 广播禁止在Internet宽带网上传输。
三、组播：
主机之间“一对一组”的通讯模式，也就是加入了同一个组的主机可以接受到此组内的所有数据，网络中的交换机和路由器只向有需求者复制并转发其所需数据。主机可以向路由器请求加入或退出某个组，网络中的路由器和交换机有选择的复制并传输数据，即只将组内数据传输给那些加入组的主机。这样既能一次将数据传输给多个有需要（加入组）的主机，又能保证不影响其他不需要（未加入组）的主机的其他通讯。
组播的优点：
1. 需要相同数据流的客户端加入相同的组共享一条数据流，节省了服务器的负载。具备广播所具备的优点。
2. 由于组播协议是根据接受者的需要对数据流进行复制转发，所以服务端的服务总带宽不受客户接入端带宽的限制。IP协议允许有2亿6千多万个（268435456）组播，所以其提供的服务可以非常丰富。
3. 此协议和单播协议一样允许在Internet宽带网上传输。
组播的缺点：
1．与单播协议相比没有纠错机制，发生丢包错包后难以弥补，但可以通过一定的容错机制和QOS加以弥补。
2．现行网络虽然都支持组播的传输，但在客户认证、QOS等方面还需要完善，这些缺点在理论上都有成熟的解决方案，只是需要逐步推广应用到现存网络当中。

今天在用JMeter做性能测试的时候，模拟了100个用户去做同一个动作的时候出现了一个错误，经过查找，发现出错的代码，应该是JMeter的Bug.

 java.io.IOException: missing CR
 at sun.net.www.http.ChunkedInputStream.processRaw(ChunkedInputStream.java:378)
 at sun.net.www.http.ChunkedInputStream.readAheadNonBlocking(ChunkedInputStream.java:493)
 at sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:584)
 at sun.net.www.http.ChunkedInputStream.available(ChunkedInputStream.java:692)
 at java.io.FilterInputStream.available(FilterInputStream.java:142)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:325)
 at java.io.FilterInputStream.read(FilterInputStream.java:90)
 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1594)
 at org.apache.jmeter.protocol.http.sampler.HTTPSampler.readResponse(HTTPSampler.java:253)
 at org.apache.jmeter.protocol.http.sampler.HTTPSampler.sample(HTTPSampler.java:463)
 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1021)
 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1007)
 at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:290)
 at java.lang.Thread.run(Thread.java:619)

问题出在ChunkedInputStream.java的代码的processRaw()中，由于没有等到'\r'标记，所以报了这个错：
                 /**
                 * Awaiting CRLF after the chunk
                 */
                case STATE_AWAITING_CHUNK_EOL:
                    /* not available yet */
                    if (rawPos + 1 >= rawCount) {
                        return;
                    }

                    if (rawData[rawPos] != '\r') {
                        error = true;
                        throw new IOException("missing CR");
                    }
                    if (rawData[rawPos+1] != '\n') {
                        error = true;
                        throw new IOException("missing LF");
                    }
                    rawPos += 2;

调高Tomcat的内存，这个问题不会再出现。