有时候人的表现欲来了，就什么都愿意说。有时候又懒到数月无话。
今天有两个有意思的事情。其实也没什么大不了的，不过还算好玩。
一个是我们一个同事启动敝公司的一个WLS server，折腾了一天，总是起不来，WLS刚启动之后就报，shutdown hook被调用了，然后就死了。作为前BEA的员工，被认为是专家，于是就得帮人消灾。先是以为是terminal退出导致SIGHUP造成的，不过一看WLS的参数里有-Xrs，看来不是signal的问题。难道有人在后台kill？用truss跟踪一下，居然看到了有SIGSEGV的消息，不过看起来不像，要是真SIGSEGV了，早就core dump了。后来想，还是老老实实配一个debugger，跟踪一下System.exit()吧。一直不想搞这个是因为eclipse连美国的机器特慢，WLS的线程又超多（我们自己也在WLS里启线程)，后来就练习了一下jdb. 虽然不够好用，不过做这个事情还是够了。要是真的是production系统上，还真可能只能用这个东西了（最好永远别用上）。结果很简单，license check的程序调了System.exit()，update一下就好了。
另外最近比较迷python。发现这个东西写程序的确比较简洁，在很多情况下可以提高productivity。比如他是不需要编译的。比如他的语法很灵活。今天学到的是用它分析一个C程序生成的数据文件。是什么C程序呢？Tokyo Tyrant，一个memcached的变种。效率不错，附带持久化。但是不知道为什么某些值总是插入失败。我们的工程师没有什么头绪。Python如何分析呢？当然得根据这个文件的结构来。这个文件(hash的数据库)先是256字节的header，然后是hash bucket*8byte的hash桶，桶里是每个record在文件中的偏移，其实就是一个索引啦。再后面是一个不知道多大的free record list，大概是指出文件中的空穴（delete带来的）。然后就是一个一个的record。
一开始还不明白该怎么搞，后来发现它的str可以放任何东西，其实就是一个byte array。(python没有byte[])。然后还有一个很强大的struct包，很容易就可以解析C的那种struct的内容。比如：
就可以得到(4, 10, 10485751, 3154959, 388634224, 83890432)，其中10485751就是bucket的大小，83890432则是第一个record的偏移量。然后从256byte开始遍历10485751个hash值，把非0的偏移的记录都读出来，结果发现，所有的199M-228M之间的内容全是0。于是得出结论说，在那个时候，应该是发生了点事情，比如硬盘满了。。。
嗯哼。满意了。不过python的IO似乎有点慢，CPU使用率很低。还要加油啊。Java现在已经很不错了。