sun的程序员也是程序员啊！

呵呵，不是我的代码了，上面贴出来的代码都是sun的。

帖子有点长，因为需要分析整个过程，如果你不关注细节，可以直接看这一行：

   public  NextAction processRequest(@NotNull Packet request) {
         if (request.endpointAddress == address)
             //  cache hit
             return  transport.processRequest(request);

问题的实质就是这个地方用 == 来比较两个实例，而这两个实例没有任何保证他们会是同一个对象的。

额，佩服楼主。

像我最多追到官方包就停了，基本不会怀疑sun的质量。不过IBM的质量我敢怀疑的，曾经追一个字符集转换的bug追到IBM JDK的官方包（是java.****，而不是com.***）。相当的鄙视IBM的代码质量。


不过，像这样的软件，基本上是靠设计和靠架构 ，整体上，设计还是非常不错滴。

这个问题是这几天才发现的，昨天上午才刚刚发现bug出现在 == 上，中午hack后测试通过才整理出来。
今天我们会联系sun，准备提交这个问题。

题外话，说说对sun的看法，或者说感情吧。

作为一个java程序员，而且是基本靠java吃饭的程序员，对于sun的感情，不言而喻。敬重，景仰，痛惜，哀其不幸，怒其不争......

sun的不幸，是大家的不幸。

以我们的产品为例，原来运行于weblogic，我们用了一年的时间做准备 + 一个团队大半年的开发时间为代码才勉强移植到glassfish，这个月就要release了。可是现在看看glassfish的前景，真是郁闷啊。

我手头正在调优的这个项目，openESB + glassfish + netbeans，还没有做完开发和测试，就已经开始要考虑替换为其他的esb实现了，因为openESB和netbeans的roadmap让我们不敢再在上面投资。

sun被收购，对我们的影响是很大的。

有兴趣的朋友可以顺便看看我的另外一个帖子

http://www.iteye.com/topic/659885

昨天下午发现并解决的问题，和这个很类似，也是metro的代码有问题，在使用hashmap时不当造成高并发下出现错误。不同的是这个bug在后来的新版本中被sun自己fix了。本来也想提交bug的，结果一查最新版本已经fix了。

太牛了！！

刚刚在java.net上注册了个账号，提交了这个bug

https://jax-ws.dev.java.net/issues/show_bug.cgi?id=854

English不怎么地，大家将就点。

现在等sun来确认和fix，不过我们自己肯定等不及，还是需要自己fix然后自己更新glassfish，这种做法以后维护很是头疼，安装部署更是费力，比较惨。

顺便推荐一个前几天发的文章，同是这次调优中发现的问题，glassfish下使用http 长连接中出现的问题和解决方法。对于使用glassfish的同学应该会有所帮助。

glassfish下的性能调优：令人极度困惑的Max Connections参数
http://www.iteye.com/topic/656368

和这两个文章有点类似，不过性质好一些，只是sun/glassfish下的属性命名和注解，文档等不一致造成理解困难。sun的命名方式太随意了一点。

前段时间看了下Cassandra的代码，也很乱。。。。错误谁都可以犯，其实这并不可怕，怕的是你都不知道犯了错

哪的程序员都是程序员， Sun, IBM, Microsoft, 甚至如日中天的Google， 都一样。
没有不犯错的程序员的。
楼主精神可嘉，值得学习。