2006年10月10日

Apache HttpClient ( http://jakarta.apache.org/commons/httpclient/ ) 是一个纯 Java 的HTTP 协议的客户端编程工具包, 对 HTTP 协议的支持相当全面, 更多细节也可以参考IBM 网站上的这篇文章 HttpClient入门 ( http://www-128.ibm.com/developerworks/cn/opensource/os-httpclient/ ).

问题分析

不过在实际使用中, 还是发现按照最基本的方式调用 HttpClient 时, 并不支持 UTF-8 编码, 在网络上找过一些文章, 也不得要领, 于是查看了 commons-httpclient-3.0.1 的一些代码, 首先在 PostMethod 中找到了 generateRequestEntity() 方法:

    /**
     * Generates a request entity from the post parameters, if present.  Calls
     * {@link EntityEnclosingMethod#generateRequestBody()} if parameters have not been set.
     * 
     * @since 3.0
     */
    protected RequestEntity generateRequestEntity() {
        if (!this.params.isEmpty()) {
            // Use a ByteArrayRequestEntity instead of a StringRequestEntity.
            // This is to avoid potential encoding issues.  Form url encoded strings
            // are ASCII by definition but the content type may not be.  Treating the content
            // as bytes allows us to keep the current charset without worrying about how
            // this charset will effect the encoding of the form url encoded string.
            String content = EncodingUtil.formUrlEncode(getParameters(), getRequestCharSet());
            ByteArrayRequestEntity entity = new ByteArrayRequestEntity(
                EncodingUtil.getAsciiBytes(content),
                FORM_URL_ENCODED_CONTENT_TYPE
            );
            return entity;
        } else {
            return super.generateRequestEntity();
        }
    }

原来使用 NameValuePair 加入的 HTTP 请求的参数最终都会转化为 RequestEntity 提交到 HTTP 服务器, 接着在 PostMethod 的父类 EntityEnclosingMethod 中找到了如下的代码:

    /**
     * Returns the request's charset.  The charset is parsed from the request entity's 
     * content type, unless the content type header has been set manually. 
     * 
     * @see RequestEntity#getContentType()
     * 
     * @since 3.0
     */
    public String getRequestCharSet() {
        if (getRequestHeader("Content-Type") == null) {
            // check the content type from request entity
            // We can't call getRequestEntity() since it will probably call
            // this method.
            if (this.requestEntity != null) {
                return getContentCharSet(
                    new Header("Content-Type", requestEntity.getContentType()));
            } else {
                return super.getRequestCharSet();
            }
        } else {
            return super.getRequestCharSet();
        }
    }

解决方案

从上面两段代码可以看出是 HttpClient 是如何依据 "Content-Type" 获得请求的编码(字符集), 而这个编码又是如何应用到提交内容的编码过程中去的. 按照这个原来, 其实我们只需要重载 getRequestCharSet() 方法, 返回我们需要的编码(字符集)名称, 就可以解决 UTF-8 或者其它非默认编码提交 POST 请求时的乱码问题了.

测试

首先在 Tomcat 的 ROOT WebApp 下部署一个页面 test.jsp, 作为测试页面, 主要代码片段如下:

<%@ page contentType="text/html;charset=UTF-8"%>
<%@ page session="false" %>
<%
request.setCharacterEncoding("UTF-8");
String val = request.getParameter("TEXT");
System.out.println(">>>> The result is " + val);
%>

接着写一个测试类, 主要代码如下:

    public static void main(String[] args) throws Exception, IOException {
        String url = "http://localhost:8080/test.jsp";
        PostMethod postMethod = new UTF8PostMethod(url);
        //填入各个表单域的值
        NameValuePair[] data = {
                new NameValuePair("TEXT", "中文"),
        };
        //将表单的值放入postMethod中
        postMethod.setRequestBody(data);
        //执行postMethod
        HttpClient httpClient = new HttpClient();
        httpClient.executeMethod(postMethod);
    }
    
    //Inner class for UTF-8 support
    public static class UTF8PostMethod extends PostMethod{
        public UTF8PostMethod(String url){
            super(url);
        }
        @Override
        public String getRequestCharSet() {
            //return super.getRequestCharSet();
            return "UTF-8";
        }
    }

运行这个测试程序, 在 Tomcat 的后台输出中可以正确打印出 ">>>> The result is 中文" .

代码下载

本文所提到的所有代码, 以及测试程序(可直接导入 eclipse)提供打包下载: att:HttpClient POST 的 UTF-8 编码问题.httpClientUTF8.tar.bz2

END

posted @ 2006-10-31 23:00 thinkbase.net 阅读(7679) | 评论 (8) | 编辑收藏

实验: 使用 Apache 反向代理实现负载均衡及热备

原文来自: 使用 Apache 反向代理实现负载均衡及热备

初步设想

早些时候在 JavaEye 上看到过一些使用 lighttpd 或者 apache 作前端, 通过负载均衡, 实现高性能的 Web 系统的讨论, 于是留意了一下这方面的技术;
考虑到对不同的 App Server 而言, 实现 Session 复制的配置各不相同(通常是需要配置集群), 因此从通用的角度, 觉得使用 session sticky 方式实现的负载均衡比较方便;
由于没有看到有资料说 lighttpd 能够实现 session sticky, 所以决定先使用 Apache 试试.

参考资料:

JavaEye 上的一篇短文: 请教apache跟tomcat做集群session不同步问题
Apache 2.2 HTTP Server 文档中的 mod_proxy 部分: 英文, 中文翻译

环境准备

下载安装 Apache, 测试时使用的是 XAMPP ( http://www.apachefriends.org/en/xampp.html ) 的 Linux 版本 (xampp-linux-1.5.4.tar.gz), 按照安装说明, 解压到 /opt/lampp 目录下就可以使用了;
- 启动 Apache: sudo /opt/lampp/lampp startapache
- 重新加载 Apache: sudo /opt/lampp/lampp reloadapache (在 httpd.conf 文件被修改后可以不重启, 而是直接 reload 就可以了)
- 停止服务: sudo /opt/lampp/lampp stop
准备两个运行同样程序的 Web 服务器, 这里使用的是 Tomcat 5.5, 并使用一个 jsp 文件作为测试文件(相关源代码参见文章最后的附件);
- 这两个 Tomcat 服务器需要将 HTTP 服务配置在不同的端口上, 同时由于测试时运行在同一台机器上, 其它端口也需要避免冲突;
下载安装 JMeter ( jakarta-jmeter-2.2), 用于压力测试, 验证负载均衡的效果;

测试 jsp 文件的说明

测试用的 jsp 文件 (test.jsp) 具有如下功能:

显示当前运行的服务器的 IP 地址及端口号, 这样从返回的页面就能够知道是运行在哪一个 Web 服务器上的了;
统计每个客户端(不同的 session)向同一台服务器发出请求的次数, 通过这个计数可以验证是否实现了 session sticky;
通过 clear 请求参数(即 .../test.jsp?clear=1)清除请求次数的计数结果, 以便进行下一次测试;
模拟 JSESSIONID +jvmRoute 的机制, 自行实现了一个 STICK_PORT_TOKEN 的 Cookie, 直接使用不同服务器的 HTTP 端口号作为 route;
- 说明1: 考虑到方案的通用性, 这里没有直接使用 JSESSIONID +jvmRoute 的机制;
- 说明2: 虽然作为一个例子, 相关代码是写死在 jsp 文件中的, 但是这个机制可以很方便的用一个 Filter 统一实现;

Apache 的配置

编辑 Apache 的 httpd.conf 文件(如果使用 xampp-linux 的话, 应该在 /opt/lampp/etc 目录下), 在文件的最后加上如下内容:

###############################################################################
# Reverse Proxy and Load Balance ##############################################
###############################################################################
# 1)简单的反向代理
ProxyRequests Off
<Proxy *>
    Order deny,allow
    Allow from all
</Proxy>
ProxyPass /1 http://localhost:8080/test
#ProxyPassReverse /1 http://localhost:8080/test
ProxyPass /2 http://localhost:18080/test
#ProxyPassReverse /2 http://localhost:18080/test
# 2)非 stickysession 的 balance
ProxyPass /3 balancer://non-sticky-cluster nofailover=On
<Proxy balancer://non-sticky-cluster>
    BalancerMember http://localhost:8080/test
    BalancerMember http://localhost:18080/test smax=10
</Proxy>
# 3)stickysession 的 balance
ProxyPass /4 balancer://sticky-cluster stickysession=STICK_PORT_TOKEN nofailover=On
<Proxy balancer://sticky-cluster>
    BalancerMember http://localhost:8080/test route=8080
    BalancerMember http://localhost:18080/test route=18080 loadfactor=2
</Proxy>

这个配置分为3个部分, 包括了 1)简单的反向代理, 2)非 session sticky 的 load balance, 以及 3)session sticky 的 load balance 三种方式的配置(这里假设两个 Tomcat 服务器的 HTTP 服务被配置在 8080 和 18080 端口), 其中第 2) 和 3) 的配置中 "nofailover=On" 适合于没有 session 复制的情况下, 这种情况下, 如果其中一台 HTTP 服务器出错, 那么原来分配在这个出错机器上的浏览器客户端不会被自动转移到另外的服务器上, 必须重新启动浏览器才能将请求分配到另外一台服务器上去.

使用 JMeter 测试结果

使用 JMeter 对 "3)session sticky 的 load balance" 的效果进行测试, 通过压力测试的方式, 检查两台 Tomcat 服务器被分配到的请求数量, 相关的测试脚本参见文章最后的附件.

注意如果重复测试, 在下一次测试开始之前请对每个 Tomcat 服务器执行 .../test.jsp?clear=1 的请求, 清除上一次的计数结果.

从下图的测试结果可见: 50个线程中有21个被分配在 8080 端口的服务器上, 29个则被分配到 18080 端口的服务器; 另外, 所有的 session 请求次数都是 20 次, 说明 session sticky 达到了预期的效果.

附件

测试用的 jsp 文件: att:使用 Apache 反向代理实现负载均衡及热备.test.jsp
JMeter 测试脚本: att:使用 Apache 反向代理实现负载均衡及热备.load-test.jmx

后记

如何禁用 XAMPP 自带的内容, 使之成为一个单纯的转发服务器:

1)注释掉 /opt/lampp/etc/httpd.conf 中 "Include etc/extra/httpd-xampp.conf" 这一行;
2)删除或者移走 /opt/lampp/htdocs 目录下的内容(但是此目录需要保留).

posted @ 2006-10-10 13:12 thinkbase.net 阅读(7031) | 评论 (7) | 编辑收藏

My Links

Blog Stats

常用链接

留言簿(5)

随笔分类

随笔档案

文章分类

搜索

最新评论

阅读排行榜

评论排行榜