Steady Says

　　上午看完变形金刚，这样的娱乐大片看了感觉就是很爽，不用为复杂的情节去思考，紧张刺激的情节中不乏幽默，最有意思是看到我们公司（Cisco Webex）在变形金刚2里做的远程恋爱系统的广告。

电影

　　在Java世界里打拼也好几年了，也看到了各种不同技术的浮浮沉沉，倒是发现了一个简单的规律，最简单的东西往往是最有用的，简单的软件也是种美。

　　在 Java Web 领域，曾经有无数各种各样的框架，Struts1/2，JSF，Echo1/2，Tapestry，Wicket，等等等等了，这么多不同的框架代表了两个不同的方向，除了 Struts 这个是基于请求的，其他几个都是算是事件驱动的，但是后面几个在整个市场上所占的份额也赶不上 Struts 一家。HTTP 请求本来是很简单的，而 Struts 就是基于这样简单的概念，但是却有无数人希望重现 VB 时代的那种拖拖拉拉的编程方式，希望用事件驱动一切，但是大部分人都失败了。失败的原因也其实不那么复杂，有的是不够成熟，像 JSF 这样被 Sun 官方大力推崇的框架，但 Ajax 出现的时候，JSF 中想灵活的用 Ajax 都成了一种奢望，有的是资料太少了。像 Echo2 这样的框架资料，少的跟珍惜保护动物似的。

　　当然也不是没有成功的，微软凭借其强大的开发实力，和开发工具的配合，加上没有给 ASP.net 用户更多选择余地，取得了无人匹敌的成功。但是这个成功在 Java 世界是不会拥有的，Java 世界没有微软这样的巨头，Java 世界中拿得出手的几个开发工具，Eclipse，Netbeans，IDEA，在所见即所得的开发上远远的落后于 Visual Studio。相比微软帝国，Java 世界多的是中小型的，开源的工具产品。规模上都远远落后于微软，Java 世界唯一可走的路便是简单了。对 Java 世界来说，简单不仅仅是种美，更是生存之道。

　　起初作为 Java 世界 PK 微软产品的重头戏，EJB 在学院派的力捧下诞生了，EJB 似乎从来都不打算让人活的轻松，一个简单的东西非得搞的复杂无比才行。而且其持久层 Entity Bean，似乎连基本功能都没能实现，更别谈大规模使用了。EJB 1/2 的时代是开发人员永远无法忘却的噩梦。

　　Java 世界也从来不缺活跃分子，Rod Johnson 这个有种音乐家气质的牛人凭借自己多年的积累，推出了 Springframework，这样一个基于 IoC 和 AOP 两个概念的简单易用的框架，完成了很多起初只有 EJB 才能完成的工作，Spring 也一夜成名，成为 Java 世界使用最为广泛的轻量级应用框架。

　　几乎是同时，来自澳洲的小帅哥 Gavin King 也在用一种与众不同的方案去替代现有比较复杂的 Java 持久化方案，最后他的 Hibernate 也成为替代原有 EJB 持久化方案的选择。相对简单的 Hibernate 也取得了巨大的成功。

　　其实这样的例子在 Java 世界也非常多，以至于后来来自于 Ruby 开发社区的 Ruby on Rails 的出现，给了 Java 开发者当头一棒，原来还有更简单的做法哦。于是 Java 世界慢慢的开始对多种脚本语言进行支持，包括 Ruby，以及后来自创的 Groovy。以此去打造类似 RoR 那样简单的开放方式。

　　生活其实是很简单的，软件开发其实也是一样，用简单的方式，去打造简单的软件，Java 世界用无数失败的教训证明了这一点。像我呢，也喜欢用这样简单的方式去工作，最喜欢 IDEA 去写代码，最喜欢 Struts2 + Spring2 + Hibernate3 这套组合，最最喜欢的是简单，因为简单是最美的工作方式。

Java, 随笔

　　前段时间一直在加班，生活，学习计划就有点乱了，这段时间稍微闲了点，开始想想未来一段时间的计划了。

　　首先嘛，得继续捡起闲置已久的 Flex 学习计划，过去在 Flex 方面的学习断断续续，并没有太大的进展，希望这次通过一个实际的应用来重新捡起 Flex 的学习，重点放在 Flex 的前端 UI 开发和同后端的整合，整合首选框架就是 BlazeDS。后端的开发继续使用 Java 已经成熟的框架。

　　学习 Flex 的主要目标是建立一个简单，高效，可以替代 ExtJS 作为前端开发的平台。积累下来的框架才是学习的真正价值所在。当然，Flex 和 ActionScript 自然也会变得比较熟练。

　　在工作方面，手上有个最为重要的项目就是 Workflow，但是估计短时间内不大有机会重新捡起来了，但是 Workflow 项目自身还是有一些不足的，一方面对工作流的模式理解不深，这个会影响到以后的项目扩展，另一方面对使用的核心引擎 jBPM 研究不够深刻，这个会影响到以后开发的工作，在工作流项目正式重新开始之前，希望能够花一些功夫把这两方面强化一下。

　　工作流系统中一个重要环节，工作流设计器，这个也是基于 Flex 的一个不错的应用，希望在进行一个简单的 Flex 应用后，完成这个流程设计器的开发工作。

　　目前的主要学习方向还是放在企业级应用方面，目前在企业级应用开发方面的优势主要在后台方面，前台方面 JavaScript 的开发比较薄弱，希望通过 Flex 弥补前端应用开发的劣势，通过 ActionScript 的学习，弥补脚本语言的一些不足。

　　之前学习一直存在个问题，就是不够专心，主要还是烦心事太多，现在不少问题都慢慢解决了，烦心事也没那么多了，希望这次能够更加专心的去学习。

计划

大清早看到新闻：北京时间4月20日晚消息，据国外媒体报道，甲骨文今天宣布，该公司将以每股9.5美元的价格收购Sun。该交易总值将超过70亿美元。

用 Google 搜索却引发了有趣的一幕，如图：

看中间一项，难不成 Oracle 也跟我们这帮开心网菜农学习，开始卖菜了？

搞笑, 随笔

HttpClient client = new HttpClient();
HttpMethod method = new GetMethod(”http://www.apache.org“);
try {
    client.executeMethod(method);
    byte[] responseBody = null;
    responseBody = method.getResponseBody();
} catch (HttpException e) {
    e.printStackTrace();
} catch (IOException e) {
    e.printStackTrace();
}finally{
    method.releaseConnection();
}

　　大部分人使用HttpClient都是使用类似上面的事例代码，包括Apache官方的例子也是如此。最近我在使用HttpClient是发现一次循环发送大量请求到服务器会导致APACHE服务器的链接被占满，后续的请求便排队等待。

　　服务器端APACHE的配置

    Timeout 30
    KeepAlive On   #表示服务器端不会主动关闭链接
    MaxKeepAliveRequests 100
    KeepAliveTimeout 180

　　因此这样的配置就会导致每个链接至少要过180S才会被释放，这样在大量请求访问时就必然会造成链接被占满，请求等待的情况。
　　在通过DEBUG后发现HttpClient在method.releaseConnection()后并没有把链接关闭，这个方法只是将链接返回给connection manager。如果使用HttpClient client = new HttpClient()实例化一个HttpClient connection manager默认实现是使用SimpleHttpConnectionManager。SimpleHttpConnectionManager有个构造函数如下：

/**
 * The connection manager created with this constructor will try to keep the
 * connection open (alive) between consecutive requests if the alwaysClose
 * parameter is set to <tt>false</tt>. Otherwise the connection manager will
 * always close connections upon release.
 *
 * @param alwaysClose if set <tt>true</tt>, the connection manager will always
 *    close connections upon release.
 */
public SimpleHttpConnectionManager(boolean alwaysClose) {
    super();
    this.alwaysClose = alwaysClose;
}

　　看方法注释我们就可以看到如果alwaysClose设为true在链接释放之后connection manager 就会关闭链。在我们HttpClient client = new HttpClient()这样实例化一个client时connection manager是这样被实例化的

    this.httpConnectionManager = new SimpleHttpConnectionManager();

　　因此alwaysClose默认是false,connection是不会被主动关闭的，因此我们就有了一个客户端关闭链接的方法。

方法一：
　　把事例代码中的第一行实例化代码改为如下即可，在method.releaseConnection();之后connection manager会关闭connection 。

　　HttpClient client = new HttpClient(new HttpClientParams(),new SimpleHttpConnectionManager(true) );

方法二：
　　实例化代码使用：HttpClient client = new HttpClient();
　　在method.releaseConnection();之后加上　((SimpleHttpConnectionManager)client.getHttpConnectionManager()).shutdown();
　　shutdown源代码很简单，看了一目了然

public void shutdown() {  
    httpConnection.close();  
} 

方法三：
　　实例化代码使用：HttpClient client = new HttpClient();
　　在method.releaseConnection();之后加上　client.getHttpConnectionManager().closeIdleConnections(0);此方法源码代码如下：

public void closeIdleConnections(long idleTimeout) {
    long maxIdleTime = System.currentTimeMillis() - idleTimeout;
    if (idleStartTime <= maxIdleTime) {
        httpConnection.close();
    }
}

　　将idleTimeout设为0可以确保链接被关闭。
　　以上这三种方法都是有客户端主动关闭TCP链接的方法。下面再介绍由服务器端自动关闭链接的方法。

方法四：
　　代码实现很简单，所有代码就和最上面的事例代码一样。只需要在HttpMethod method = new GetMethod(”http://www.apache.org“);加上一行HTTP头的设置即可
　　method.setRequestHeader(”Connection”, “close”);

　　看一下HTTP协议中关于这个属性的定义：
　　HTTP/1.1 defines the “close” connection option for the sender to signal that the connection will be closed after completion of the response. For example,
       Connection: close
　　现在再说一下客户端关闭链接和服务器端关闭链接的区别。如果采用客户端关闭链接的方法，在客户端的机器上使用netstat –an命令会看到很多TIME_WAIT的TCP链接。如果服务器端主动关闭链接这中情况就出现在服务器端。
　　参考WIKI上的说明http://wiki.apache.org/HttpComponents/FrequentlyAskedConnectionManagementQuestions
　　The TIME_WAIT state is a protection mechanism in TCP. The side that closes a socket connection orderly will keep the connection in state TIME_WAIT for some time, typically between 1 and 4 minutes.
　　TIME_WAIT的状态会出现在主动关闭链接的这一端。TCP协议中TIME_WAIT状态主要是为了保证数据的完整传输。具体可以参考此文档：
http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-socket-faq-2.html#ss2.7
　　另外强调一下使用上面这些方法关闭链接是在我们的应用中明确知道不需要重用链接时可以主动关闭链接来释放资源。如果你的应用是需要重用链接的话就没必要这么做，使用原有的链接还可以提供性能。

HttpClient