JAX-WS threads consuming %100 CPU

I have a web service exposed with Spring and JAX-WS. I used jax-ws commons to do that (http://jax-ws-commons.java.net/spring/). Application is deployed on weblogic 10.3 and sometimes some of the threads seem to be stucked. Tha last time I get a thread dump, I saw that 6 threads were marked as "STUCK" and those threads were consuming %100 CPU. The trace of the threads were like the following:

        "[STUCK] ExecuteThread: '7' for queue:开发者_如何学Python 'weblogic.kernel.Default (self-tuning)'" daemon prio=10 tid=0x00002aaaec5f8800 nid=0x3d99 run
nable [0x0000000048ca4000]
    java.lang.Thread.State: RUNNABLE
        at java.util.HashMap.put(HashMap.java:374)
        at java.util.HashSet.add(HashSet.java:200)
        at weblogic.wsee.jaxws.ServerLateInitTube.initializeCopy(ServerLateInitTube.java:56)
        at weblogic.wsee.jaxws.ServerLateInitTube.copy(ServerLateInitTube.java:45)
        at weblogic.wsee.jaxws.ServerLateInitTube.copy(ServerLateInitTube.java:24)
        at com.sun.xml.ws.api.pipe.TubeCloner.copy(TubeCloner.java:102)
        at com.sun.xml.ws.api.pipe.TubeCloner.clone(TubeCloner.java:74)
        at com.sun.xml.ws.server.WSEndpointImpl$2.<init>(WSEndpointImpl.java:251)
        at com.sun.xml.ws.server.WSEndpointImpl.createPipeHead(WSEndpointImpl.java:250)
        at com.sun.xml.ws.api.server.Adapter$Toolkit.<init>(Adapter.java:108)
        at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.<init>(HttpAdapter.java:434)
        at com.sun.xml.ws.transport.http.HttpAdapter.createToolkit(HttpAdapter.java:203)
        at com.sun.xml.ws.transport.http.HttpAdapter.createToolkit(HttpAdapter.java:99)
        at com.sun.xml.ws.api.server.Adapter$1.create(Adapter.java:117)
        at com.sun.xml.ws.api.server.Adapter$1.create(Adapter.java:115)
        at com.sun.xml.ws.util.Pool.take(Pool.java:78)
        at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:248)
        at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:140)
        at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)
        at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160)
        at com.sun.xml.ws.transport.http.servlet.WSSpringServlet.doPost(WSSpringServlet.java:52)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
        at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
        at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292)
        at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3594)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
        at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2202)
        at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108)
        at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

Do you have any ideas why there are stucked threads?

---

The put method of non synchronized HashMap is most probably called from multiple threads. I faced the very same issue when had large number of calls to HashMap's put method from multiple threads.

---

You most likely have a non-terminating loop in your code, causing this to happen.

Either run under a debugger and pause the program when symptoms show to investigate the current state of each thread, or use JVisualVM in the JDK to attach to a running program and get a thread dump.

Based on this knowledge you can decide where the bottleneck is and then deduce how to fix it.

---

I opened an SR to Oracle and they sent a patch for this problem. Problem seems to be fixed with the patch.

---

http://mailinator.blogspot.com/2009/06/beautiful-race-condition.html would explain it, I think