You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Daniel Kulp (JIRA)" <ji...@apache.org> on 2010/10/01 19:46:33 UTC
[jira] Resolved: (CXF-2992) response context concurrent issue
[ https://issues.apache.org/jira/browse/CXF-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-2992.
------------------------------
Fix Version/s: 2.3
2.2.11
Resolution: Fixed
> response context concurrent issue
> ---------------------------------
>
> Key: CXF-2992
> URL: https://issues.apache.org/jira/browse/CXF-2992
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.2.2
> Environment: Java: Java(TM) 2 Runtime Environment, Standard Edition (IBM build 1.5.0_16-b02
> 20080907 (SR8 + IZ29767 + IZ30684 + IZ31214 + IZ31213)) Java HotSpot(TM) Server VM
> Os: SunOS 5.10 Generic_142900-03 sun4v sparc SUNW,SPARC-Enterprise-T5220
> Reporter: Justinas Dabravolskas
> Assignee: Daniel Kulp
> Fix For: 2.3, 2.2.11
>
>
> After running an application with CXF for longer time, we have some threads(4-5) that are using about 100% cpu each. It occurred three times already and the only solution to this problem is to restart an application server.
> PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID
> 10992 was 97 0.0 0.0 0.0 0.0 2.7 0.0 0.0 3 43 7 1 java/966
> 10992 was 97 0.0 0.0 0.0 0.0 2.7 0.0 0.0 3 40 7 1 java/491
> 10992 was 97 0.0 0.0 0.0 0.0 2.7 0.0 0.0 3 60 7 1 java/1251
> 10992 was 97 0.0 0.0 0.0 0.0 2.7 0.0 0.0 3 102 7 1 java/1280
> All hung threads has the same stack trace "default-workqueue-232" prio=3 tid=0x00000001065c2c50 nid=0x4e3 runnable [0xfffffffdf86fe000..0xfffffffdf86ff9a8]
> at java.util.HashMap.put(HashMap.java:420)
> at java.util.HashMap.putAll(HashMap.java:570)
> at org.apache.cxf.endpoint.ClientImpl.processResult(ClientImpl.java:520)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:659)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2132)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:2020)
> at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:243)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> at java.lang.Thread.run(Thread.java:595).
> ClientImpl tries to add response message to response context and it enters into an infinitive loop inside HashMap. (line 420 for (Entry<K,V> e = table[i]; e != null; e = e.next) )
> Though at first glance response context is access based on the current thread, I think the only possible way HashMap may enter this infinitive loop is concurrent modification somewhere inside CXF code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.