You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Justinas Dabravolskas (JIRA)" <ji...@apache.org> on 2010/09/14 14:10:33 UTC
[jira] Created: (CXF-2992) response context concurrent issue
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
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.
[jira] Assigned: (CXF-2992) response context concurrent issue
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp reassigned CXF-2992:
--------------------------------
Assignee: Daniel Kulp
> 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
>
> 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.
[jira] Updated: (CXF-2992) response context concurrent issue
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp updated CXF-2992:
-----------------------------
Fix Version/s: (was: 2.2.11)
(was: 2.3.0)
2.3.1
2.2.12
> 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.2.12, 2.3.1
>
>
> 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.
[jira] Resolved: (CXF-2992) response context concurrent issue
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ 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.