<?xml version="1.0" encoding="UTF-8"?><!-- generator="WordPress/2.9.1" -->
<rss version="0.92">
<channel>
	<title>kafka0102的边城客栈</title>
	<link>http://www.kafka0102.com</link>
	<description>要有最朴素的生活与最遥远的梦想，即使明日天寒地冻、路远马亡。</description>
	<lastBuildDate>Sat, 18 Jun 2011 04:20:42 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	
	<item>
		<title>开源分词程序ki-analyzer启动</title>
		<description><![CDATA[ki-analyzer 是基于ik-analyzer 修改而来的分词程序，所以名字上只是简单的变了一下，源码方面还是沿用了ik的包名等。之所以在ik-analyzer之上山寨另一个轮子，也实在是因为我的需求ik-analyzer不能很好满足，并且功能、设计、改动方面较ik-analyzer有很大出入，所以另起山寨。ik-analyzer项目现在还活着，前不久发布了新版，貌似只是源码实现细节的调整，项目也不是很活跃。当然，国内的几个开源分词程序基本都停滞了。ki-analyzer程序是上周修改的，这周实际测试了一下，只能说bug方面基本稳定，但尚需进一步检验。因为一些想要的功能暂时还用不上，所以也没着急做。关于ki-analyzer的详细情况可以参考项目首页信息，对该项目感兴趣或有问题的朋友可以联系我。]]></description>
		<link>http://www.kafka0102.com/2011/06/453.html</link>
			</item>
	<item>
		<title>Double.NaN != Double.NaN</title>
		<description><![CDATA[昨天做数据时发现个很诡异的情况，当然，再诡异的技术现象也有起发生原因。抛开我的问题来说，我可以再提出个问题：是否在某种编程语言中，存在着那么一个变量i，使得i!=i成立，也使得while(i==i);可以成功的退出？如果你想到并理解了，你可以终止阅读这篇可能冗长的文章，尽管为了填补这个月的博客空白我刻意小题大作一番。在java语言中，Double.NaN就能使得上面两个表达式成立。]]></description>
		<link>http://www.kafka0102.com/2011/05/439.html</link>
			</item>
	<item>
		<title>理解mongodb的ObjectId</title>
		<description><![CDATA[	mongodb支持的数据类型中，ObjectId是其自有产物，本文对其做些简单的介绍。
	存储在mongodb集合中的每个文档（document）都有一个默认的主键_id，这个主键名称是固定的，它可以是mongodb支持的任何数据类型，默认是ObjectId。在关系数据库schema设计中，主键大多是数值型的，比如常用的int和long，并且更通常的，主键的取值由数据库自增获得，这种主键数值的有序性有时也表明了某种逻辑。反观mongodb，它在设计之初就定位于分布式存储系统，所以它原生的不支持自增主键。而现实的世界是，大量应用在可预见的时空里并不需要分布式的mongodb，所以网上就出现了大量的实现mongodb自增主键方法的文章。恩，我之前也干过这种事情。]]></description>
		<link>http://www.kafka0102.com/2011/03/435.html</link>
			</item>
	<item>
		<title>夜说mongodb</title>
		<description><![CDATA[赋闲以后很长没有更新博客了，说忙完全是借口，多半因为没有兴致所致。今天凌晨比赛多多，趁着比赛的前奏和间隙，遂浏览些技术文章。发现了 highscalability.com整理出了wordnik使用mongodb和scala的使用经 验：http://highscalability.com/blog/2011/2/15/wordnik-10-million-api- requests-a-day-on-mongodb-and-scala.html。这个wordnik也算是mongodb的先驱应用者之一，并贡献了一些管理工具给社区，去年的mongoSF大会也有它的参与：http://www.slideshare.net/fehguy /migrating-from-mysql-to-mongodb-at-wordnik。]]></description>
		<link>http://www.kafka0102.com/2011/02/430.html</link>
			</item>
	<item>
		<title>searchblox&#8211;一个基于lucene的搜索产品</title>
		<description><![CDATA[前两天在solr邮件组看到一封广告帖，一个叫searchblox的搜索产品可免费使用，好奇心驱使我简单了解并使用了一下。searchblox是基于lucene的搜索解决方案，现在的版本已经是6.1,看来也有些年头了。searchblox不是个开源产品，有免费的版本，也有收费的版本，看文档介绍，收费版本除了提供服务支持还多了复制功能。]]></description>
		<link>http://www.kafka0102.com/2010/12/425.html</link>
			</item>
	<item>
		<title>Solr复制bug一例：Unable to move index file from tempfile to indexfile</title>
		<description><![CDATA[22日下午3时多，收到搜索系统的报警邮件，错误日志如下：
[2010-11-22 15:16:14][ERROR][pool-6-thread-1][SnapPuller.java(650)]Unable to move index file from: /indexpath/index.20101122031500/_21.frq to: /indexpath/index.20101122031000/_21.frq
	SnapPuller是Solr复制用到的一个类，我对它做了一些修改，所以把它挪到我的代码里了。报错的代码片断如下：]]></description>
		<link>http://www.kafka0102.com/2010/11/414.html</link>
			</item>
	<item>
		<title>httpclient的并发连接问题</title>
		<description><![CDATA[	昨天的搜索系统又出状况了，几个库同时重建索引变得死慢。经过一个上午的复现分析，确定问题出现httpclient的使用上。搜索系统在重建索引时，是并发多个线程（默认是8个）不停的从PHP客户端取数据（当然，从另一个角度来说，搜索系统是客户端，PHP端是服务端），取回后放到一个队列里由单独的一个线程更新索引。在测试环境复现发现，对于一个请求，PHP端打印耗时是1-2秒，但搜索端打印在4-6秒。这种耗时差别也就两种可能性，一个是PHP端返回到搜索端接受完耗时太长，另一个就是搜索端在真正发给PHP端数据前等待了很久。因为有了之前的jetty7的困顿，起初我怀疑是传输数据的问题。因为请求数据的代码部分我只是简单的使用了httpclient，所以只能从httpclient着手分析。我想到把PHP端和搜索端的请求起始和结束时间都打出来对照一下，不过在这样做之前我把搜索端的并发请求线程数调到了1,看下单线程情况下效果如何，结果惊奇地发现PHP端和搜索端的耗时相近。所以，可以确定，是httpclient的并发连接处理上可能存在问题。]]></description>
		<link>http://www.kafka0102.com/2010/11/405.html</link>
			</item>
	<item>
		<title>solr拾遗：引用计数</title>
		<description><![CDATA[	据我不完全统计，solr代码中使用引用计数的用途有两种：一个是引用资源，一个是引用对象。技术上来说引用计数的使用没多少可大说的，不过如果没有正确的close获得的资源和对象，泄漏的bug就出现了。]]></description>
		<link>http://www.kafka0102.com/2010/11/401.html</link>
			</item>
	<item>
		<title>oracle提升mysql售价，误解与无视</title>
		<description><![CDATA[前几天就在twitter上看到oracle提升mysql售价的消息，推上的英文圈对oracle的这一举动议论纷纷，但中文圈很是平静，倒是像 csdn、javaeye这样的媒体做头条报道：Oracle提高了MySQL的售价。这一新闻难免又引起大家对mysql前景的悲观，对迁移存储系统到postgre、nosql等蠢蠢欲动。其实多数mysql使用者可以轻松的忽略这一新闻，因为人家 oracle提价mysql影响的是买收费版本mysql的用户，并不会影响我等使用免费版本的用户。
]]></description>
		<link>http://www.kafka0102.com/2010/11/397.html</link>
			</item>
	<item>
		<title>solr拾遗：CopyField</title>
		<description><![CDATA[	solr的index schema中，除了支持基本数值类型的field，还支持一些特别的field，比如较常用的CopyField。以下面的schema配置片断为例：

&#60;schema name=&#34;eshequn.post.db_post.0&#34; version=&#34;1.1&#34;
    xmlns:xi=&#34;http://www.w3.org/2001/XInclude&#34;&#62;
     &#60;fields&#62;
     	&#60;!-- for title --&#62;
        &#60;field name=&#34;t&#34; type=&#34;text&#34; indexed=&#34;true&#34; stored=&#34;false&#34; /&#62;
        &#60;!-- for abstract --&#62;
        &#60;field name=&#34;a&#34; type=&#34;text&#34; [...]]]></description>
		<link>http://www.kafka0102.com/2010/10/394.html</link>
			</item>
	<item>
		<title>各种java序列化工具性能对比</title>
		<description><![CDATA[看到一个很不错的工具http://github.com/eishay/jvm-serializers/，可以用它来评测各种流行的java序列化反序列化工具的性能，使用上也很简单。想试试该工具的，下载源码后参考起README操作即可。而我更关心的是，是各种工具的性能对比，以作选择的一个衡量标准，也就是http://github.com/eishay/jvm-serializers/wiki的图示和数据。本文也就简单转摘其图示，图示中的java-manual指的是根据对象（数据）格式手工操作（当然是最快的，但不具有通用性），java- buildin-in就是内置的序列化方式（ObjectOutputStream、ObjectInputStream），其他工具的使用版本可以查看其wiki。]]></description>
		<link>http://www.kafka0102.com/2010/10/383.html</link>
			</item>
	<item>
		<title>mysql的多线程复制</title>
		<description><![CDATA[对于使用主从复制的mysql用户来说，经常会遇到的问题是，当主库的写压力增大时，基于单线程复制的从库跟不上主库的写速度，造成应用从从库读到脏数据。如果在数据库前面使用了cache，那么这种脏数据的影响就更恶劣。更糟糕的是，如果在主库上执行了耗时很长的sql，那么从库就会被完全阻塞，这也限制了程序员们不要在主库执行耗时长的语句，更不要提那些alter schema的语句。对于mysql主从的这个缺陷，可以使用一些其他方式规避它，比如做sharding处理，控制每个master的写压力在合适的范围内，也可以去主从，通过应用来分发请求到各个db（应用相当于主库），但这些做法相比复制无疑会复杂的多。]]></description>
		<link>http://www.kafka0102.com/2010/10/380.html</link>
			</item>
	<item>
		<title>solr filter query的误用</title>
		<description><![CDATA[在我整理solr SolrIndexSearcher性能问题分析的时候，我就在想，我是不是误用了SolrIndexSearcher，才出现我所以为的性能问题。当我想到其实现特点，我恍惚确定确实是这样的，根源就是我误用 filter query。上篇文章暂且放下，这篇做个补充。如我上文所述，fq=fid:1这个条件匹配的文档数会很多，不过，如果开启了filter cache，那么只会在第一次调用时慢些，后续的调用都会命中cache而提升速度，而通过query预热是可以解决初次调用的低速问题。所以，如果要使用filter query，就要开启filter cache，并确保filter cache能容纳所有的filter query。这也需要对应用的查询特点做好分析。以fq=atm:[int_time1 TO int_time2]为例，我之前是将它放到filter query中，不过因为每次查询的int_time1和int_time2都几乎不相同，使得总不能命中filter cache，严重影响了查询性能。另一方面，我在做压力测试时也发现，当filter query结果充满了filter cache，最终使得程序内存耗尽。]]></description>
		<link>http://www.kafka0102.com/2010/10/374.html</link>
			</item>
	<item>
		<title>solr SolrIndexSearcher性能问题分析</title>
		<description><![CDATA[基于solr的新搜索系统已经使用了有段时间，不过之前上的几个库都很小，也没发现什么性能问题。最近上了thread和post库后，性能问题显现出来。这段时间解决的性能问题有好几个，本文只着重于SolrIndexSearcher的search问题。thread库索引大小有400M多，记录数有400多万，原来的基于lucene的系统的查询处理耗时一般在10-30ms，而同样的请求，新系统耗时在50-100ms。而post库索引大小有 6G多，记录数有3000多万，旧系统的查询处理时间一般在30-80ms，而新系统往往需要400-800ms，性能差距还是很明显的。
因为SolrIndexSearcher是基于lucene的IndexSearcher，想必应该是青出于蓝胜于蓝，并且其wiki上给出的性能数据也很不错，所以当我把新系统做完后并没有去细致的测试其性能。但现在系统的性能相比之下确实有些差，并且因为要做多个库的整合搜索，就要避免像thread 这样耗时长的库就成为短板。总之，问题需要定位和解决。]]></description>
		<link>http://www.kafka0102.com/2010/10/366.html</link>
			</item>
	<item>
		<title>分享：Scalable System Design Patterns</title>
		<description><![CDATA[Scalable System Design Patterns 一文概括了几种常见的系统设计模式。配图很漂亮，我就索性摘过来，推荐感兴趣的继续围观其博客。]]></description>
		<link>http://www.kafka0102.com/2010/10/350.html</link>
			</item>
	<item>
		<title>twitter的新搜索架构</title>
		<description><![CDATA[当习惯于粗略浏览google reader中的未读条目后便似完成任务般的“全部标记已读”，我就经常性的错过不错的精彩条目，比如这篇 Twitter's New Search Architecture。我是订阅了engineering.twitter.com的，但这并不影响我没有注意到它就把它mark过。今天看到这篇文章时，已经有别的网站将该文翻译成中文了，比如新 Twitter，新搜索，比如 新 Twitter，新搜索，我在这也就算是炒冷饭了。]]></description>
		<link>http://www.kafka0102.com/2010/10/347.html</link>
			</item>
	<item>
		<title>Is Terracotta&#8217;s BigMemory a big thing?</title>
		<description><![CDATA[Terracotta最近推出了个新东西--BigMemory，使得Infoq上的这篇Terracotta's BigMemory Aiming to Eliminate Garbage Collection for Java Caches文章引来长长的争论。像GigaSpaces、Infinispan等和Terracotta有竞争关系的商业或开源的对手，对BigMemory的诸多方面提出了疑问和质疑。如果BigMemory真的如Terracotta吹的那般好，那些竞争对手该情何以堪？就算它真的好，也要挑出它的不是，比如就有评论说现在都分布式年代了，还搞什么单JVM实例优化？暂且放下这些争论，看看BigMemory是个怎样的东西，值得大家如此大动神经。]]></description>
		<link>http://www.kafka0102.com/2010/09/343.html</link>
			</item>
	<item>
		<title>Facebook的Online Schema Change for MySQL</title>
		<description><![CDATA[Feng的 Facebook 针对 MySQL 开源 Online Schema Change 代码 介绍了 Facebook最新开源的在线修改mysql schema的工具，并对该工具极尽赞扬之辞。于是乎，我这个有大半年没动过mysql的人翻看起该工具的文档Online Schema Change for MySQL，并简单的浏览了其代码OnlineSchemaChange.php。总的来说，尽管其实现思想很朴素，这个工具真的很实用，它借鉴的openark-kit似乎发布了很长时间，只是名头没有Facebook的guys响亮，知道的人似乎不多。openark上的其他工具也很不错，比如ycheckpoint，就是个很不错的监控mysql运行状态的工具。]]></description>
		<link>http://www.kafka0102.com/2010/09/338.html</link>
			</item>
	<item>
		<title>分享：Playfish&#8217;s Social Gaming Architecture</title>
		<description><![CDATA[highscalability.com上的Playfish's Social Gaming Architecture - 50 Million Monthly Users and Growing是篇很不错的大杂烩，内容涉及全球第二大social game公司Playfish的技术架构、产品设计、团队协作、产品运营等诸多经验之谈，尤其对初创团队很有借鉴意义。我这里还只是对文中提到的一些技术经验做些汇总，也推荐大家去浏览原文，重点看看自己感兴趣的段落。但说起架构的事情，其实看多了，往往都是大方向上相似，细节上有自己的考量和特点，以形成自己的架构风格。]]></description>
		<link>http://www.kafka0102.com/2010/09/333.html</link>
			</item>
	<item>
		<title>mongodb MapReduce使用初步</title>
		<description><![CDATA[	最近在做搜索的查询日志的统计分析，对每一条查询统计日志，我将其解析出来后以特定字段格式存在mongodb中，定时调度做些统计分析。其中有个需求是，统计某个时间段（每天、每周、每月）各个query的查询次数，展示上就是热门查询query了。考虑到处理的数据量不会很大，解决方法也可以简单来之。我现在使用的方法就是mongodb的MapReduce功能，其实这个需求也可以认为是个group操作，而mongodb的group功能就是基于MapReduce的，但group对结果集的大小是有限制的。本文就针对一个示例介绍一下mongodb MapReduce功能。]]></description>
		<link>http://www.kafka0102.com/2010/09/329.html</link>
			</item>
	<item>
		<title>[Solr实践]自定义SolrEventListener实现searcher的autowarm策略</title>
		<description><![CDATA[	Solr的searcher autowarm（预热）有两个时机，一个是系统启动时（firstSearcher），一个是使用新的searcher替换旧的searcher时（newSearcher）。Solr支持在solrconfig.xml中对SolrCore配置SolrEventListener来实现自定义的autowarm。通常来说，Solr提供的默认实现QuerySenderListener就够用了。在我的需求中，希望solrconfig.xml中配置的SolrEventListener是针对多个SolrCore的，这要是因为我的多个SolrCore共用了一个solrconfig.xml配置。就配置autowarm的查询query来说，简单的就是配置一个常见的query，但如果系统有排序查询（sort），可以配置适宜的sort条件以预热lucene的fieldCache。下面是我自定义的SolrEventListener，效果是，如果SolrCore没有配置query，就使用default的，否则使用自己的。]]></description>
		<link>http://www.kafka0102.com/2010/09/326.html</link>
			</item>
	<item>
		<title>Solr之困</title>
		<description><![CDATA[重写公司的站内搜索。经过前期一段时间对lucene和solr的熟悉，最后决定使用Solr作为新系统的基础框架。现在已经是第一阶段开发的后期，核心代码行数有11000+（不包含admin及client等）。现已实现的功能要比已有系统要丰富些，但综合比较两个系统总的代码量，其实新系统并不多得太多。新系统使用Solr代替了已有系统实现的部分功能，这减少了新系统的代码量，同是新系统实现了已有系统不具有的功能，也增加了一些代码量。开发的这段时间，因为新系统中很多代码是独立于Solr的，所以和Solr的交互也是时断时续，以使得即便到了开发后期我还能发现Solr实现的一些细节带给我的困扰。]]></description>
		<link>http://www.kafka0102.com/2010/08/319.html</link>
			</item>
	<item>
		<title>HttpClient的“Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.”警告释疑</title>
		<description><![CDATA[使用HttpClient，总是报出“Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.”的WARN日志，定位到HttpClient的源码如下：

    public byte&#91;&#93; getResponseBody&#40;&#41; throws IOException &#123;
        if &#40;this.responseBody == null&#41; &#123;
            InputStream instream = getResponseBodyAsStream&#40;&#41;;
     [...]]]></description>
		<link>http://www.kafka0102.com/2010/08/316.html</link>
			</item>
	<item>
		<title>构建健壮的Java基准测试</title>
		<description><![CDATA[本周遇到几篇和基准测试相关的不错的文章，如果不是因为上周末鼓弄了一下各种锁的性能测试，我或许就会错过它们。两篇文章来自dw，分别是 Robust Java benchmarking, Part 1: Issues 和  Robust Java benchmarking, Part 2: Statistics and solutions，作者还有个专页 Java benchmarking article 提供一个Java基准测试的框架，感兴趣的可参考之。本文算是对Robust Java benchmarking, Part 1: Issues的一个简单的总结。在阅读Robust Java benchmarking两篇文章的过程中，我也看了些其中的参考文章，也有一些不错的可以拜读之。]]></description>
		<link>http://www.kafka0102.com/2010/08/312.html</link>
			</item>
	<item>
		<title>Java中各种锁类型的基准性能评测</title>
		<description><![CDATA[周末对Java中各种类型的锁做了基准评测。测试的条件有两个：1）是10、50、100个不同的并发线程，2）是读写比例近似1:1,10:1,100:1,1000:1。测试方法是，对各种加锁的Map方法做性能评测，它们都是实现了MapWrapper接口的封装，测试的就是Map的get和put方法。测试的锁类型有：1）hashtable：直接测试Hashtable，2）synclock：对HashMap的方法直接加synchronized（理论上性能应和Hashtable相当），3）mutexlock：对HashMap的方法显示加Lock锁，4）rwlock：对HashMap加读写锁，5）concrrent：直接使用ConcurrentHashMap的方法，6）对HashMap读操作不加锁，写操作加Lock。]]></description>
		<link>http://www.kafka0102.com/2010/08/298.html</link>
			</item>
	<item>
		<title>[Solr源码分析]LRUCache和FastLRUCache实现分析</title>
		<description><![CDATA[	在 [Solr 实践]Solr Cache使用介绍及分析 一文我有对Solr的LRUCache和FastLRUCache做了一些介绍，本文在此基础对其实现做些补充。
1、LRUCache的实现分析
	在分析LRUCache前先对LinkedHashMap做些介绍。LinkedHashMap继承于HashMap，它使用了一个双向链表来存储Map中的Entry顺序关系，这种顺序有两种，一种是LRU顺序，一种是插入顺序，这可以由其构造函数public LinkedHashMap(int initialCapacity,float loadFactor,                   boolean accessOrder)指定。所以，对于get、put、remove等操作，LinkedHashMap除了要做HashMap做的事情，还做些调整Entry顺序链表的工作。
	以get操作为例，如果是LRU顺序（accessOrder为true），Entry的recordAccess方法就调整get到的Entry到链表的头部去：

   public V get&#40;Object key&#41; &#123;
        Entry&#60;K,V&#62; e = &#40;Entry&#60;K,V&#62;&#41;getEntry&#40;key&#41;;
        if &#40;e [...]]]></description>
		<link>http://www.kafka0102.com/2010/08/293.html</link>
			</item>
	<item>
		<title>分析多线程并发写HashMap线程被hang住的原因</title>
		<description><![CDATA[在blogjava上看到一文  谁能帮忙解释一下为什么这个程序会死锁？，激发了我那能害死猫的好奇，所以很费劲的琢磨了这个问题。由于涉及的内容较多，就单独发文阐述一下。
文中提到的问题程序如下：

public class TestLock &#123;
  private final HashMap map = new HashMap&#40;&#41;;
  public TestLock&#40;&#41; &#123;
    final Thread t1 = new Thread&#40;&#41; &#123;
      @Override
      public void run&#40;&#41; &#123;
        for&#40;int i=0; i&#60;500000; i++&#41; &#123;
 [...]]]></description>
		<link>http://www.kafka0102.com/2010/08/286.html</link>
			</item>
	<item>
		<title>PHP中的“syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM”错误</title>
		<description><![CDATA[因为需要，今天晚些在本机使用PHP做些测试，PHP脚本依赖了一堆我也不清楚做什么用的库。结果一跑起来，就报出类似下面的错误：“Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in /home/kafka/test/test.php on line 8”。查找代码，发现报错的代码类似：“$class_name::func1();”，也就是使用一个表示类名的字符串变量来调用它的静态方法，并且是解析时的语法错误（我第一眼看到::时，脑子里浮现的是C++里的作用域符号，好长时间后才想起PHP里有::也有这种东西，我也是用过 self::doSomething()的）。]]></description>
		<link>http://www.kafka0102.com/2010/08/281.html</link>
			</item>
	<item>
		<title>[Solr实践]Solr Cache使用介绍及分析</title>
		<description><![CDATA[	本文将介绍Solr查询中涉及到的Cache使用及相关的实现。Solr查询的核心类就是SolrIndexSearcher，每个core通常在同一时刻只由当前的SolrIndexSearcher供上层的handler使用（当切换SolrIndexSearcher时可能会有两个同时提供服务），而Solr的各种Cache是依附于SolrIndexSearcher的，SolrIndexSearcher在则Cache生，SolrIndexSearcher亡则Cache被清空close掉。Solr中的应用Cache有filterCache、queryResultCache、documentCache等，这些Cache都是SolrCache的实现类，并且是SolrIndexSearcher的成员变量，各自有着不同的逻辑和使命，下面分别予以介绍和分析。]]></description>
		<link>http://www.kafka0102.com/2010/08/267.html</link>
			</item>
	<item>
		<title>使用JRebel提供对Java web开发的热部署</title>
		<description><![CDATA[	这几天在写Java Web页面，开发环境是linux+eclipse+maven+jetty。开发java web最烦的就是改个文件需要重启web server，尽管现在的web server（比如小野猫）支持了热部署，不过其实现相当于重启了web server，如果文件多些初始化复杂些，重启的时间也够受的。对于开发的IDE来说，myeclipse是个不错的选择，它能对修改的文件自动部署到web server（eclipse wtp就没做这个支持，但我们也可以投机的对部署目录和开发目录做个软链），不多我试用了其最新的8.5版本，在本本上响应速度有些迟缓，影响编码情绪。而且，因为环境需要，最后开发环境定位eclipse+maven+jetty（maven提供了jetty的plugin用于开发测试），并且找到了JRebel这个强悍的能提供对Web server的热部署到工具，它不像web server那样需要重启服务，而是动态的加载修改的文件，所以反应速度上要好很多，它除了可以热加载class、jsp文件，也可以是spring、hibernate等配置文件。]]></description>
		<link>http://www.kafka0102.com/2010/07/258.html</link>
			</item>
</channel>
</rss>

