|
锁定老帖子 主题：sun的程序员也是程序员啊！(续)
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-05-05
最后修改：2010-05-05
刚刚鄙视完sun，继续performance tuning，结果又发现问题：测试中，偶尔会出现一些古怪错误，经检查，发现有以下可疑的异常：
[#
|
2010
-
05
-
05T14:
27
:
37.295
+
0800
|
WARNING
|
sun
-
glassfish
-
comms
-
server2.
0
|
com.sun.jbi.httpsoapbc.OutboundMessageProcessor
|
_ThreadID
=
53
;_ThreadName
=
HTTPBC
-
OutboundReceiver
-
47
;_RequestID
=
42321e60
-
6723
-
4831
-
a99a
-
b4dd1ac3e35f;
|
HTTPBC
-
E00759: An exception occured
while
processing a reply message. HTTP transport error: java.util.ConcurrentModificationException
com.sun.xml.ws.client.ClientTransportException: HTTP transport error: java.util.ConcurrentModificationException at com.sun.xml.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java: 134 ) at com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java: 143 ) at com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java: 89 ) at com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java: 91 ) at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java: 595 ) at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java: 554 ) at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java: 539 ) at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java: 436 ) at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java: 106 ) at com.sun.xml.ws.tx.client.TxClientPipe.process(TxClientPipe.java: 177 ) at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java: 115 ) at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java: 595 ) at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java: 554 ) at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java: 539 ) at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java: 436 ) at com.sun.xml.ws.client.Stub.process(Stub.java: 248 ) at com.sun.xml.ws.client.dispatch.DispatchImpl.doInvoke(DispatchImpl.java: 180 ) at com.sun.xml.ws.client.dispatch.DispatchImpl.invoke(DispatchImpl.java: 206 ) at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.outboundCall(OutboundMessageProcessor.java: 1256 ) at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.dispatch(OutboundMessageProcessor.java: 1296 ) at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processRequestReplyOutbound(OutboundMessageProcessor.java: 747 ) at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processMessage(OutboundMessageProcessor.java: 257 ) at com.sun.jbi.httpsoapbc.OutboundAction.run(OutboundAction.java: 63 ) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 886 ) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: 908 ) at java.lang.Thread.run(Thread.java: 619 ) Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java: 793 ) at java.util.HashMap$EntryIterator.next(HashMap.java: 834 ) at java.util.HashMap$EntryIterator.next(HashMap.java: 832 ) at com.sun.xml.ws.transport.http.client.HttpClientTransport.createHttpConnection(HttpClientTransport.java: 364 ) at com.sun.xml.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java: 118 ) ... 25 more
final
Entry
<
K,V
>
nextEntry() {
if (modCount != expectedModCount) throw new ConcurrentModificationException();
HashIterator() {
expectedModCount = modCount; ... }
/**
* The number of times this HashMap has been structurally modified * Structural modifications are those that change the number of mappings in * the HashMap or otherwise modify its internal structure (e.g., * rehash). This field is used to make iterators on Collection-views of * the HashMap fail-fast. (See ConcurrentModificationException). */ transient volatile int modCount;
public
Packet process(Packet request) {
HttpClientTransport con; try { // get transport headers from message Map < String, List < String >> reqHeaders = (Map < String, List < String >> ) request.invocationProperties.get(MessageContext.HTTP_REQUEST_HEADERS); // assign empty map if its null if (reqHeaders == null ){ reqHeaders = new HashMap < String, List < String >> (); } ...... for (Map.Entry < String, List < String >> entry : reqHeaders.entrySet()) { httpConnection.addRequestProperty(entry.getKey(), entry.getValue().get( 0 )); }
public
Packet process(Packet request) {
HttpClientTransport con; try { // get transport headers from message Map < String, List < String >> reqHeaders = new HashMap < String, List < String >> (); Map < String, List < String >> reqHeadersInRequest = (Map < String, List < String >> ) request.invocationProperties.get(MessageContext.HTTP_REQUEST_HEADERS); // assign empty map if its null if (reqHeadersInRequest != null ){ reqHeaders.putAll(reqHeadersInRequest); }
http:
//
fisheye5.cenqua.com/browse/jax-ws-sources/jaxws-ri/rt/src/com/sun/xml/ws/transport/http/client/HttpTransportPipe.java?r1=1.14&r2=1.15&u=3&k=kv
可以参考我之前的一个blog， http://www.blogjava.net/aoxj/archive/2010/04/29/319706.html，在解决这里提到的http long connection 和 TIME_AIT的问题之前，我们的tps比较低，cpu压不上去，当时好像这个问题不明显。后来搞定之后tps上来了才暴露出来。 考虑上一个blog中 == 比较无效导致cache失效的bug，我对metro的代码质量真是很没有信心。按说这样的大型项目，release之前怎么也要做做压力测试，稳定性测试之类，很容易发现类似问题才是。我相信，不是每个用metro的地方，tps都只需要跑几十tps而已吧。我在我的普通开发机上做测试，大概只能跑到100个tps，没有发现出错。换到比较强劲的机器，tps上到1000后，上面的错误立即凸现。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2010-05-06
最后修改：2010-05-06
感觉这样从新putAll一个新对象会很耗费内存，如果在多线程，大数据量的情况下。concurrentHashMap吧，这可能又需要修改其他实现的代码了。。。
不过同步的这个包是后来发布的，可以理解。 3篇文章我都看了，很佩服楼主的钻研精神。刚才没赶上点精华，这里补一个吧。 
|
| 返回顶楼 | |
|
发表时间：2010-05-06
最后修改：2010-05-06
prowl 写道 感觉这样从新putAll一个新对象会很耗费内存，如果在多线程，大数据量的情况下。concurrentHashMap吧，这可能又需要修改其他实现的代码了。。。
不过同步的这个包是后来发布的，可以理解。 3篇文章我都看了，很佩服楼主的钻研精神。刚才没赶上点精华，这里补一个吧。 谢谢，谢谢！ putAll只是将对象引用复制一份作为新的hashmap的key/value，仅仅增加了一个hashmap + 一堆key/value引用，内存应该不是问题，不过cpu消耗会多一点。 修改之后的代码，我们昨天晚上跑了6个小时，没有再出现上面的异常，问题应该是解决了。 |
| 返回顶楼 | |
|
发表时间：2010-05-06
ConcurrentModificationException 我们项目中也遇到过。解决的思想和楼主是一样的。
|
| 返回顶楼 | |
|
发表时间：2010-05-06
楼主好文章
|
| 返回顶楼 | |
|
发表时间：2010-05-06
深奥得看不懂...
|
| 返回顶楼 | |
|
发表时间：2010-05-06
请教一下，多线程的压力测试工具用的啥？ 是loadrunner么？
|
| 返回顶楼 | |
|
发表时间：2010-05-06
压力测试是自己写多线程么
|
| 返回顶楼 | |
|
发表时间：2010-05-06
牛 虽然看得不是很懂
|
| 返回顶楼 | |
|
发表时间：2010-05-06
最后修改：2011-03-09
cassandra里也有同样的问题, 这个东西其实挺常见的.
|
| 返回顶楼 | |
