无言独上西楼，就菊花古剑和酒，醉里挑灯看剑。问明月，我是谁。

　　前阵听同事说东莞局的一个业务自八月起就无法核准，而且该业务自上线使用以来，系统生成的证照号就一直是441900x-1。惊奇（一年多不正常，居然没有听到任何反映）之余，便让他们再试一次，以便从日志分析。从日志上看，核准时取到了一个状态不正常的数据库连接（事务未完成的）。理论上，如果连接池中存在状态不正常的连接，那么任何时业务都有可能取到该连接，从而出错，而不应该仅仅是东莞的某个业务。 (more…)

　　看过 BlueDavy 关于 OSGi 介绍的博客后，不禁对它充满了好奇（深层次的原因是没有搞明白 OSGi 是什么）。于是便上 OSGi 官方网站，看过首页还是没有明白 OSGi 倒底是什么。
　　在快速 view 了技术白皮书前几页后，大致明白了 OSGi 是做什么的。
　　可以认为 OSGi 提供了一个愿景：当客户需要一个应用系统的时候，他不需要找开发商从头做起，而是根据自己的需要，到市场上购买服从 OSGi 的、合适的组件（包），然后自己组装、配置，搞掂。就如同现在咱们随时可以上电脑市场买一块 PCI-E 的显卡、DDR 内存条什么的，也不用管它什么牌子，直接插入机器就可以使用。乌托邦式的愿景。正如那个脱衣服的似鱼非鱼的家伙所说的，“可惜用户一般都是一般用户”。的确，又有多少用户有这种组装、配置能力？当然，可以通过一个中间层（系统组装专业户？）来层接。
　　在本质上，OSGi 与 IoC 并没有不同，它们的区别主要在粒度上。IoC 是强制基于对象的开发，通过框架用对象来组装对象；OSGi是强制基于组件的开发，通过框架用组件来组装应用。
　　当然，学习 OSGi 仍然是必须的。

Powered by ScribeFire.

　　安装完 Platform SDK 后，按照 MSDN 上 Using Visual C++ 2005 Express Edition with the Microsoft Platform SDK 一文配置好项目，满以为这次可以构建成功了。结果出来一个 LINK : fatal error LNK1104: cannot open file ‘atlthunk.lib’ 的错误。晕倒，M$ 的东东怎么这样？在本机上搜索了一阵，没有能找到此文件。于是祭起 google 大法，嘿嘿，还有人遇到过此问题，有方法说是要修改 atl.h ，屏蔽掉对 atlthunk.lib 的引用。照做，终于构建成功！严重 BS M$。
　　构建完成之后，多思考了一个问题：Jacob 1.13 与 1.12 的本地代码有哪些主要区别？大致看了一下，发现 1.13 中全部用安全的字符串函数替换了传统的字符集函数，如用 strcpy_s  替换 strcpy。从《编写安全的代码》一书中，可以知道 M$ 自己应该是把所有的传统字符串函数换成了安全的字符串函数。于是又引出一个问题：此次测试中，开发公司的开发人员前后所使用的 Jacob 版本是否都是 1.13？如果不是，显然很有可能与这些安全的字符串函数相关，回想前几日 debug 的代码片断，还真有点象是 strcpy/strcat 之类的。
　　还没有来得及打电话确认，就出差了。看来下周再说了。
　　奇怪的是 Jacob 的开发人员为什么不使用  strncpy。

Powered by ScribeFire.

　　关于并发调用 Jacob 时容易导致 JVM crash 一事，一直怀疑是二进制兼容问题，之前让Simon 在 Windows 2003 上重新构建 jacob 的本地代码，即 jacob.dll。最近一次问他此事，答复是开发人员用 VC 无法构建，说是少些文件，也未能在 jacob 网站上找到。
　　我自是不相信 Jacob 会在发布包里犯这么大的错误，于是便下载并安装了 VC++ 6。 (more…)

　　前不久 simon 说 Jacom 1.13 引入了一个创建 ActiveXComponent 实例的新方法，经过他们测试，在六七个人并发操作的情况下，JVM 还没有宕机。言下之意，不外是采用新方法，可以解决 Jacob 并发时易导致 JVM Crash 的问题。
　　当真如此？ (more…)

　　JVM 的运行参数原本配置有 +PrintGCDetails ，输出的日志自是详细记录了 GC 的活动，包括各 generation 的收集情况。然而，在配置了 +UseParallelGC 之后，检查 GC 日志，却发现回到了最初的状态，各 generation 的细节没有了。晕！
　　应该是个 bug 吧，不查了，累。

Powered by ScribeFire.

　　今天不知是什么运气，居然在 generation gc 时，JVM 宕掉了。晕，以前是在 full gc 时。
　　上次配置了增量 gc ，阿洪反映系统很慢，又改回去了，具体是不是增量 gc 惹的祸，没有亲眼看到，呵呵。
　　好了，这次就配置个并行 gc 吧，希望好运。
　　

Powered by ScribeFire.

　　仍然有较频繁的 JVM Crash 现象，不排除系统中多处使用 Jacob 的功能并发导致。其实一直还有另一个疑惑：perm gen 扮演了什么角色？每个 dump 日志均有如下信息：

compacting perm gen total 77312K, used 77260K [0×50010000, 0×54b90000, 0×58010000)
the space 77312K, 99% used [0×50010000, 0×54b83258, 0×54b83400, 0×54b90000)

　　JVM 的配置里，MaxPermSize 是 128M，在日常运行过程中，通过 visualgc 观察，perm gen 通常也不到 70M。为什么 compacting perm gen 显示 99% used？这里面应该有几个概念：一是 compacting perm gen 是怎样定义的？二是 JVM 是如何管理 perm gen 的？是一次性分配完 MaxPermSize，还是先占位，然后根据实际需要分配？
　　加上 -XX:+PrintGCDetails，输出详细 GC 日志，再观察。
　　在观察过程中，很快就 crash 了一次，此时 perm gen 才使用约 71M。显然，与 perm gen 没有实质的关系。同时也可以推断 perm gen 的管理应该是采用第二种模式。

Powered by ScribeFire.

     From TSS

* #10 – Excessive logging
* #9 – Incorrect application server configuration
* #8 – Incorrect usage of Java EE
* #7 – Unnecessary use of XML
* #6 – Improper caching
* #5 – Excessive memory usage
* #4 – Badly performing libraries
* #3 – Incorrectly implemented concurrency
* #2 – Unnecessary remoting
* #1 – Incorrect database usage

Powered by ScribeFire.

　　今天阿洪反映系统有时仍然会自动消失，于是上去看了看系统 crash 时产生的日志文件，如下：

# Java VM: Java HotSpot(TM) Server VM (1.4.2_10-b03 mixed mode)
# Problematic frame:
# V [jvm.dll+0x1b4609]
#

VM_Operation (0×05b3f46c): full generation collection, mode: safepoint, requested by thread 0×035bd340

　　显然，Full GC 导致了 JVM Crash。
　　搜索 J2SE 1.4.2 的 release note，发现 ID 为 6268279 的 bug，
6268279 hotspot compiler2 Full GC causes core
　　然而，这个 bug 是在 1.4.2_10-b03 中 fixed 的！
　　别一方面，从 gc 日志来看，系统的内存占用一直在稳步上升，当达到近 900M 时，一个 Full GC 的请求出来了，但没有能完成，系统就 crashed。
　　虽然仍然怀疑是 JRE 的 bug，但是没有证据。唉，只能从解决内存只涨不跌的方向着手了。之前的观察已经发现对 Jacob 的错误调用会导致内存泄露，而最近更新后，Jacob 的调用变得更频繁，虽然实际上并不需要使用，完全可以用 POI。代码的修改周期太长，只能转向 JVM 本身，先试试增量 GC。

Powered by ScribeFire.