什么是纠结？纠结就是…

apache httpd 2.2.8 + mod_proxy_ajp，以及tomcat
6.0.14，httpd会时不时地把应该发给用户A的内容发送给用户B。tcpdump显示，完全是tcp级别的纠结：httpd甚至不等tomcat
从AJP
link发送回响应就把已有的一个应该发给另外一个连接的响应给发送了出去。所有的server都是从一个镜像复制出来的，但只有这个server，也是
产品正式上线前最重要的一个server，纠结到了这个程度…
于是乎，请求一个图片，返回一个css；请求一个css，返回一个js；某请求应该会拿到302跳转，结果返回一个应该显示给手机客户端的xml文档…
升级了下httpd到最新发行版，发现还是那个德行，然后在我们还在睡觉时被某人幸灾乐祸似的赶紧麻地利儿地又恢复到了2.2.8——稳定性，这是我在这
公司里最反感的一个说词：明明就是不稳定到无以复加的程度…有bugfix都不跟上，让人怀疑隐约是怕万一升级错了就得被人半夜从被窝里拎出来飙到机房。
其实apache出regression的频率和概率比我们自己要小很多——我不是说没出过。
httpd
2.2.8的代码放在机器里N天了，ctags也跑了一趟，就是没有时间看：因为要和人解释为什么我说这不是我们自己代码（java）出问题造成的，因为
有人怀疑我们自己的代码（java）已经神到可以corrupt整个java
runtime从而导致tomcat返回错误的响应了。我从来是不会说"不可能"的人，只不过这事儿概率太小了，小到基本上等于我们team一起买了彩票
能瓜分整个奖池的概率。
反正那台server也已经被f*ck到这地步了，备用server也已经有人在申请了，准备搞个lighttpd上去试一下，毕竟apache错发响应
是实实在在被tcpdump下来了的，此外还有一次怀疑是某cache的shability。同时翻翻bugzilla以及svn log。
于是搞的我也很纠结：我是来修我们自己的java bug的吔…
圡鳖就需要受到SM级别的震慑。

Locating the Guilty Java Threads

A summary of my recent experience with resolving an 100% CPU utilization issue.

We know well that in Java 5 and above we have the mighty java.lang.management.ThreadMXBean
which is able to give us almost all ordinary diagnostics information of
a given thread, except more detailed information that only debuggers
are able to tell. However, such information is implementation/vendor
dependent and some information, like CPU time measurement, might be
disabled by default, and moreover, in my humble opinion, these
information may be not very accurate since they are reported by the JVM
itself, not by the OS.

Luckily, almost every popular OS supports some means of
measurements down to the threading level, and on the Java side, we have
the thread dump (of course, also in popular JVM implementations). I’m
here taking Ubuntu, Windows XP with SUN JVM (5.0 for Windows and 6.0 for Linux) as an example. This example demonstrates the process to find the thread that is utilizing unusual amount of CPU time in a Tomcat instance hosting a very simple web application.

When there’s something wrong caused by the JVM, say, similarly, it
simply occupies all CPU time, you can always find the guilty threads by
doing so:
1. Getting threading information from the OS.
In most Linux distros, a single ps command can handle this. For instance,
ps H -eo user,pid,ppid,tid,time,%cpu,cmd –sort=-%cpu
, will print out all the processes and their created threads, sorted by
the percentage of overall CPU utilization. We can always RTFM for more
information about *nix commands;)

In Windows, however, getting threading information for a
process might be harder. I suggest using Process Explorer, which is the
most easy to use tool amongst other equivalents.

First of all, open the "Properties" dialog of the JVM process.

Next, click on the "Threads" tab to see threads of the process. You can see that they are sorted by CPU utilization by default.

(I have a dual core CPU and this thread is occupying a whole core)
2. Getting a thread dump from JVM.

This task should be easier for us as Java developers;) In Linux we use kill -3 PID,

(I was running less logs/catalina.out after the thread dump, because I wrongly started Tomcat by bin/catalina.sh start instead of bin/catalina.sh run. Never mind)
and in Windows we can simply hit Ctrl+Break in the console window that is running the JVM process.


3. Finding out the Java thread from

Usually the thread ID printed by the OS are in decimal format, and
this value needs to be converted into a hexadecimal. And next, no other
magic other than finding "nid=xxx" terms in the thread dump. See highlighted parts:

7772=0x1E5C

2148=0x864


Yep,
that’s it, test.Test.test();. I’m not going to amuse you by posting
the source of test.Test.test(), since it’s no more than an infinite
loop:D

Regards and hope this helps.

Oops

Programmer:
// muhaha
String test = "blahblahblah";
String str = new String(test + " is OK" + ", damn it.");

Compiles to:
JVM INSTR start_warning "Alert! Eden generation, you’ll be shooted with a bunch of temporary Objects!" ;
0:ldc1 #16 <String "blahblahblah">
2:astore_1
3:new #18 <Class java.lang.String>
6:dup
7:new #20 <Class java.lang.StringBuilder>
10:dup
11:aload_1
12:invokestatic #22 <Method java.lang.String java.lang.String.valueOf(java.lang.Object)>
15:invokespecial #26 <Method void StringBuilder(java.lang.String)>
18:ldc1 #29 <String " is OK">
20:invokevirtual #31 <Method java.lang.StringBuilder java.lang.StringBuilder.append(java.lang.String)>
23:ldc1 #35 <String ", damn it.">
25:invokevirtual #31 <Method java.lang.StringBuilder java.lang.StringBuilder.append(java.lang.String)>
28:invokevirtual #37 <Method java.lang.String java.lang.StringBuilder.toString()>
31:invokespecial #41 <Method void String(java.lang.String)>
34:astore_2
JVM INSTR start_warning "Please the GC thread heal our poor Eden…" ;

某些人学聪明了~

为了让自己显得更NB一些，我决定不鸟tomcat打包好的源代码，而是去svn co出来。机器上残存的tomcat源代码还是5.0的，心疼地在硬盘上一通删之后，开始co出tc5.5.x相关代码，包括container、connectors、jasper、servletapi以及大杂烩build这5跎。

结果co出jasper时就出问题，总是connection timed out，直接在Firefox里打开jasper的repository的URL也是超时，想co出build来也是一个下场，于是信以为真地以为asf在盘点，就先搁置。但是container要依赖build，eclipse里看那么个红叉始终还是不爽，隔了些分钟后遂尝试继续co，继续超时……

刚才没事儿干的时候通过tor做代理浏览了下jasper和build这两个项目的repository，竟然可以，而且不用tor的话还是打不开。不得不说，某些人聪明了，不再用connection reset来提醒大家浏览了不利于构建和谐社会的东西了，而是蔫吧啦唧的把包全丢了算了，靠est，co点代码搞的跟地下工作者一样，真和谐。

这不叫聪明，老大们。

Technorati : china, gfw

初步认识Firefox

用了Firefox也有一段时间了，当它还叫做Firebird的时候我就已经好奇的装上了它。那个时候除了IE以外我还装了Mozilla(Suite)，真正是个庞然大物，后续版本经常建议在系统启动时运行它那个QuickLaunch，以便在用户真正需要浏览器的时候确保Mozilla(Suite)的一些组件已经装载了，否则那启动时间真是无与伦比，无论是想简单的用Mozilla Chat上个IRC还是用浏览器开它十几个tab。

貌似跑题了……

昨天闲来无事，焚香静坐后学习了一下Firefox的扩展机制，嗯，扩展，extension，而不是可能被一些人说为插件（plugin）的东西，我记得我以前好像唠叨过二者的不同，plugin应该更底层一些。看来我一直的理解还是有问题，在我的想法里Firefox作为浏览器来说还是一个真刀真枪的本地代码拼装起来的东西，那些UI控件还是用的操作系统的那套，只不过人家用了一些招数把跨平台的部分用代码封装起来，看上去比较类似wxWidgets、Qt之类的库，只不过全面一些，但其实上Firefox的方法来的更为颠覆一些，那就是浏览器上能看到的一切皆是XUL。

打开Firefox，映入眼帘的这个可爱的界面，无论你应用了什么外观主题，堆砌了多少扩展，它都是一个XUL文档（chrome://browser/content/browser.xul），查看$FIREFOX_DIR/chrome/browser.jar!/content/browser/browser.xul，这就是每天你面对着的这个界面，哦，它当然不包括Google Toolbar，没有AdBlock，这些都是通过扩展完成的，而不用直接修改这个XUL文档的内容。Firefox使用的XUL Overlay正是扩展和主题得以完成的根本，使用过程中感觉XUL Overlay很直观，无论是当作Overlay的XUL文档还是被Overlay的XUL文档，与普通的XUL文档都没有任何区别，除了一个描述清单（chrome.manifest）以外没有再多的废话，想改变哪里，就在Overlay XUL文档里描述你的界面你的想法，再向chrome.manifest里添加一行描述Overlay关系的指令（或许有其他方法描述？直觉那些RDF很不简单），然后把这些东西打包当作扩展安装，重启Firefox之后就能看到改变。用XUL的好处是任何人不用依赖任何开发工具就能很好的制作扩展，如果像我一直以为的那种依赖本地代码的应用的话，那就只有拥有熟练开发本领的专业人员才能制作扩展，或者像Maxthon一样依赖HTML，但HTML终究能力有限，其要解决的问题是显示，而不是要制造一套完整的UI解决方案，即使也可以像XUL一样使用javascript，但诸如command、commandset甚至数据源之类的高级货还是缺乏的，而且，虽然利用HTML也可以描出XUL中的所有控件，但模型上还是稍微有些差距，比如命令和事件以及数据源，好在经过Ajax的一阵吹风，HTML+Javascript也重新焕发光彩，用Dojo这样比较完善的东西来实现XUL也不是没有可能，然而还是那句话，模型上的差距，是HTML没法追上的，相反的在表现方式上XUL和HTML一样也有差距不是~

收获就是做了一个简单的扩展，用来在浏览flickr上的图片时直接访问原始图片:P 还有就是意外的发现了为什么Firefox有的时候可能让人觉得反应迟缓：阅读Firefox自己的chrome里的Javascript代码的时候，发现了很多调用setTimeout来延迟某些方法调用的地方，这些地方大部分是为了确保诸如文档（包括HTML以及XUL）加载、更新全局变量的完成，避免出现意外，比如在文档没有加载的时候去访问文档的属性及其内部变量，或者在全局变量上发生同步错误，导致一些灵异现象。我试了试直接调用被延迟调用的方法，其实这些方法的速度还是很快的。

可能做页面做多了，Greasemonkey的user scripts也做多了，在编写扩展中的javascript的时候总是搞混document对象，因为我还是试图用自己熟悉的方法，通过HTMLDocument来调用已经用烂了的那些方法，后来自己抽自己一下，提醒自己一定要用XUL文档里的元素提供的方法。

这几年真是白用Firefox了，竟然才知道Firefox究竟是个什么东西。用XULRunner（GRE）外加全套XUL、XPCOM来做浏览器的做法实在够cool，给我的感觉像是以UI驱动的Java=) Sigh，我还一直奇怪那么多号称基于"Firefox、Mozilla架构"的应用是怎么做出来的了，实在是老土的不行了……

Technorati : firefox

新版Google Reader

貌似一小时前Official Google Blog和Official Google Reader Blog才放出的消息，当然，当时从Google Reader里阅读这些消息的我已经用上新版Google Reader了

估计这次改版，一直以来对Google Reader的平板式阅读不满的那些拥护Bloglines类型的分类树形的人们可能会稍微满意一些，因为我刚刚习惯了的平板式阅读又被颠覆了回去

不过依然是做了些变化，比如默认情况下在Expanded View中，随着阅读部分的滚动会自动将滚过的feed item设置为已阅读的状态，相比那种点了一个feed就把所有其下的feed item全置为已读状态的武断做法来说要好上太多。

废话不多说，主要还是想了一下这个从平板式阅读到比较老式的分类树形阅读的改变。原先的平板阅读加label的方法在我看来和tag的用法是一致的，但对我而言我也并非经常打label，好的我就打星，没有消化掉的就Mark as Unread，加label一般都是在添加feed时，这样一来这个feed下的所有item也就都具有这个feed的label，意义确实不是很大，因为谁也没法保证一个feed下的所有item就都如此统一一致，如果真的想有效管理这么多item，可能就不得不经常性去改某些item的label了，但有时这真的很烦人，而且在一个Reader里改来改去，就好比在报纸上做笔记，一来麻烦，二来比较分散。现在Google Reader又采用了老式的分类树形方式组织feed，我觉得，tag还是比较适合对大量数据的分众分类，而对feed这样的用户已经进行过筛选的东西，以及对协作要求不高的事情来说，做些分类还是一个可行方法。

就最近做网站的经验，tag实在是一个很棒的方法，一来分众分类强过网站自己的主观分类，二来用户对tag的使用实际也是方便自己收藏、分类，但同时也能反映出这个用户的一些偏好或者寻求信息的趋势，这对提供个性化服务应该是个不错的指导，就像Google会记录你搜过什么关键词一样。

Google Calendar中文版

还不错，字也很大。

用上了XGL

照着UbuntuGuide.org的一则wiki，一点力气都没费就享受到了这么牛叉的东西，有机会抓图上来，太帅了。
如果不是那些IE only的网站和开发习惯让我还不得不用着win（外加最近还落入游戏的陷阱里……），日常使用方面win真的也比不上Ubuntu Linux了。

休息一下

请了半天假，到家只剩下半天的半天，不管怎么样也算休息了，先打个盹睡上一小觉……

起来后照常上Google Reader看新东西，Firefox 2.0 beta 2出炉算个不小的消息，看来大家用的都比较舒服，我也去下了一个，估计肯定要遇到扩展的兼容性问题，所以没覆盖老的1.5安装，不过打开一看常用的插件（AdBlock Plus!，Cookie Safe，FireBug，FlashBlock，FlashGot，FoxyProxy，FoxyTunes，Google Browser Sync，Google Notebook以及Google Toolbar）还都能用–至少显示着能用的样子，看来一会儿满可以覆盖了老的1.5安装了=)

公司自己开发并运营的网站–健康114–今天正式对外发布，boss还参加了个新闻发布会什么的。面对着这个让整个公司忙活了近3个月的网站，我不知道该做何感想。3个月前我记得我是满腔热情的投入进来；2个月前我一个人负责的社区模块刚刚处于设计阶段，感觉还算不错；1个月前是魔鬼开发，同时网站基本成形，那个时候如果让我相信这个东西能带来收入我一定不信；今天它正式上线了，不管它在我眼里还有多少不足之处。下一个开发阶段马上又要开始了，我只希望能多休息一下。

还有，喜欢上了Garnet Crow的Mysterious Eyes，很不错的一首歌，可以从emule上 下载 。

Technorati : firefox

Google Picasaweb发布

地址：http://picasaweb.google.com/，注册（或者是激活？）很简单，输入Google Account就成了。

界面还算简洁，和GMail、Google Reader的风格不太一致，但挺好看，Photo Chooser也很好玩。上传图片可以在浏览器里上传，也可以用新版的Picasa，下载地址：http://dl.google.com/picasa/picasaweb-setup-beta.exe。

让我很关心的还是空间和展示图片的限制问题，flickr的类似限制最近被很多人提出来，尤其是限制200张图片的问题。看了一下Picasaweb的Learn More，解释的好像不是太清楚，或者说是我还报着一点奢望……如下：

Storage: Each Picasa Web Albums account comes with 250MB of free storage space, or room to post and share approximately 1,000 wallpaper-sized photos (at 1600 pixels each). For $25.00 per year, users can get a subscription to an additional 6GB of storage – room to post and share approximately 25,000 photos.

也没说是不是每个月250M…啊我承认太贪心了，flickr每个月才给免费用户20M，不过日久天长每个月20M就很多了…

让我觉得好笑的是，picasaweb应该检查了HTTP Referer了，所以在非google.com域以外的地方都没法打开，这里的截图只好借flickr宝地一用了……

Technorati : google, picasaweb