11 Replies Latest reply on May 17, 2014 3:43 PM by CaptainGoldfish

    JAX-WS Deadlock


      Hey guys,


      I'm trying to communicate with a test-WebService via soap. The problem is, that my code (only 5 lines long) results in a deadlock. Up to now I had no luck reporting this at stackoverflow and another java forum, so I hope that someone here can help.


      I use the following wsdl and created the corresponding files with:


      wsimport -keep -extension http://ars-fiverx.de:8445/WsEchoService.svc?wsdl


      my Code then looks as follows.


              URL url = new URL("http://ars-fiverx.de:8445/WsEchoService.svc?wsdl");
              QName qname = new QName("http://tempuri.org/", "WsEchoService");
              Service service = Service.create(url,qname);
              IWsEchoService iWsEchoService = service.getPort(IWsEchoService.class);
              // deadlock comes with call to sysout.


      For testing I pushed the request onto a proxy to watch what exactly is happening. My client sends a GET-Request to the server and the server responds. But that's it. No termination no further responding - deadlock.

      The link is currently available and anyone should be able to reproduce this error. I tried it also without proxy, I tried it from another computer with an another environment and I have absolutely ne idea what actually is happening.


      hope that someone is able to help... almost lost hope on this issue.

        • 1. Re: JAX-WS Deadlock

          What does a thread dump of your program show when it is deadlocked?

          • 2. Re: JAX-WS Deadlock

            cool I didn't even know that I could do that. But after you said it, I made the thread dump. Problem is just that I do not know what to do here.


            2014-05-14 22:26:16
            Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode):
            "Monitor Ctrl-Break" daemon prio=6 tid=0x000000000cc97000 nid=0x15ac runnable [0x000000000d17f000]
               java.lang.Thread.State: RUNNABLE
                at java.net.DualStackPlainSocketImpl.accept0(Native Method)
                at java.net.DualStackPlainSocketImpl.socketAccept(DualStackPlainSocketImpl.java:131)
                at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398)
                at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:198)
                - locked <0x00000007d56aa4a8> (a java.net.SocksSocketImpl)
                at java.net.ServerSocket.implAccept(ServerSocket.java:530)
                at java.net.ServerSocket.accept(ServerSocket.java:498)
                at com.intellij.rt.execution.application.AppMain$1.run(AppMain.java:82)
                at java.lang.Thread.run(Thread.java:744)
            "Service Thread" daemon prio=6 tid=0x000000000acdf000 nid=0x1398 runnable [0x0000000000000000]
               java.lang.Thread.State: RUNNABLE
            "C2 CompilerThread1" daemon prio=10 tid=0x000000000acde000 nid=0x13e4 waiting on condition [0x0000000000000000]
               java.lang.Thread.State: RUNNABLE
            "C2 CompilerThread0" daemon prio=10 tid=0x000000000acd8000 nid=0x1290 waiting on condition [0x0000000000000000]
               java.lang.Thread.State: RUNNABLE
            "Attach Listener" daemon prio=10 tid=0x00000000026bc000 nid=0xafc waiting on condition [0x0000000000000000]
               java.lang.Thread.State: RUNNABLE
            "Signal Dispatcher" daemon prio=10 tid=0x000000000acd7000 nid=0x1348 runnable [0x0000000000000000]
               java.lang.Thread.State: RUNNABLE
            "Finalizer" daemon prio=8 tid=0x000000000acb6000 nid=0xff4 in Object.wait() [0x000000000c67f000]
               java.lang.Thread.State: WAITING (on object monitor)
                at java.lang.Object.wait(Native Method)
                - waiting on <0x00000007d5605568> (a java.lang.ref.ReferenceQueue$Lock)
                at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
                - locked <0x00000007d5605568> (a java.lang.ref.ReferenceQueue$Lock)
                at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
                at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
            "Reference Handler" daemon prio=10 tid=0x000000000acb5000 nid=0x161c in Object.wait() [0x000000000c57e000]
               java.lang.Thread.State: WAITING (on object monitor)
                at java.lang.Object.wait(Native Method)
                - waiting on <0x00000007d56050f0> (a java.lang.ref.Reference$Lock)
                at java.lang.Object.wait(Object.java:503)
                at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
                - locked <0x00000007d56050f0> (a java.lang.ref.Reference$Lock)
            "main" prio=6 tid=0x000000000258e000 nid=0xe9c runnable [0x000000000256e000]
               java.lang.Thread.State: RUNNABLE
                at java.net.SocketInputStream.socketRead0(Native Method)
                at java.net.SocketInputStream.read(SocketInputStream.java:152)
                at java.net.SocketInputStream.read(SocketInputStream.java:122)
                at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
                at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
                at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
                - locked <0x00000007d5dfc280> (a java.io.BufferedInputStream)
                at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687)
                at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:633)
                at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323)
                - locked <0x00000007d5dea0a0> (a sun.net.www.protocol.http.HttpURLConnection)
                at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468)
                at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(HttpClientTransport.java:192)
                at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(HttpTransportPipe.java:212)
                at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:203)
                at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:122)
                at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:123)
                at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:626)
                at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:585)
                at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:570)
                at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:467)
                - locked <0x00000007d5dd26e8> (a com.sun.xml.internal.ws.api.pipe.Fiber)
                at com.sun.xml.internal.ws.client.Stub.process(Stub.java:308)
                at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:163)
                at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:98)
                at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
                at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:135)
                at com.sun.proxy.$Proxy28.echo(Unknown Source)
                at de.narz.fiverx.fiverx_v2_0_Client.FiveRX_v2_0_Client.main(FiveRX_v2_0_Client.java:63)
                at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
                at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                at java.lang.reflect.Method.invoke(Method.java:606)
                at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
            "VM Thread" prio=10 tid=0x000000000acb3000 nid=0x15b8 runnable
            "GC task thread#0 (ParallelGC)" prio=6 tid=0x00000000025d7000 nid=0x1114 runnable
            "GC task thread#1 (ParallelGC)" prio=6 tid=0x00000000025d8800 nid=0x2e8 runnable
            "GC task thread#2 (ParallelGC)" prio=6 tid=0x00000000025da000 nid=0x1728 runnable
            "GC task thread#3 (ParallelGC)" prio=6 tid=0x00000000025dd000 nid=0x450 runnable
            "GC task thread#4 (ParallelGC)" prio=6 tid=0x00000000025df000 nid=0xdf0 runnable
            "GC task thread#5 (ParallelGC)" prio=6 tid=0x00000000025e1000 nid=0xfd8 runnable
            "VM Periodic Task Thread" prio=10 tid=0x000000000ad05800 nid=0x176c waiting on condition
            JNI global references: 173


            line 69 of this matches the sysout line above.

            • 3. Re: JAX-WS Deadlock

              So the key bit is the "main" thread:

              "main" prio=6 tid=0x000000000258e000 nid=0xe9c runnable [0x000000000256e000]  
                 java.lang.Thread.State: RUNNABLE
                  at java.net.SocketInputStream.socketRead0(Native Method)


              This shows that the the jax-ws call is hanging waiting for a network response.  this means that either you have a network problem, or the server is not responding.  You said in your original post that "the server responds", but this stack trace gives no indication that the server has responded.

              • 4. Re: JAX-WS Deadlock

                But that is not true. I wrote the same client with ruby and this works perfectly. Today I made a workaround. I created the soap message wrote it into a file and have sent it via HttpClient to the server. This worked too.

                And as I said I tried it from two different locations. So it is not a network problem. And I said before that I also have tried too redirect the request to a proxy who showed to me that the server does respond!

                • 5. Re: JAX-WS Deadlock

                  Well, that is what the stacktrace indicates.  what version of java are you using?  also, it looks like you are testing from within intellij.  have you tried running your program as a standalone application?  sometimes jars within the ide can cause conflicts.

                  • 6. Re: JAX-WS Deadlock

                    I use java 7.0.55. But I also tried it with java 6.0.45 and got the same error. And I also tried to run it from netbeans but that did not help either. I am completely clueless about this issue. Might this be a bug in the jax-ws implementation? I gave all the information needed to try this in my first report. And I bet if you try to run it you will get the same error.

                    • 7. Re: JAX-WS Deadlock

                      No, it is not a bug in JAX-WS. JAX-WS can't help it that a socket connection gives no response. That's like blaming the bus driver for being stuck in traffic.

                      • 8. Re: JAX-WS Deadlock

                        alright I see, that was a stupid thought. But I have no control over that socket. I really used just these 5 lines of code above. That's the whole program plus the generated sources from the wsdl. Is there anything I can do about this?

                        • 9. Re: JAX-WS Deadlock

                          First you have to find the source of the problem, you can't cut corners and make the problem go away by snapping your fingers. I sincerely hope there is someone close by to you who can support you in investigating the problem. I'm pretty sure its not a code problem.


                          Welcome to the wonderful world of software engineering by the way. If you thought it was about writing code, you were wrong. This is it. I hope you can find it in your strength to turn this into a challenge rather than a bother, or else I fear this job is not for you. Good luck digging into this.

                          • 10. Re: JAX-WS Deadlock

                            You are correct, i can try it myself.  i ran the code myself through a proxy and saw exactly what i said, the server is not sending a response.  So, either you are sending a bad request, or the server is broken.


                            If you can get the call to work from some client/language and not another, the best thing to do is run both calls through an http proxy and compare the successful request with the failed request.  Then, once you identify the difference, you can see if there's additional jax-ws configuration tweaks you need to make to make it work correctly.

                            • 11. Re: JAX-WS Deadlock

                              thx for the help so far. I will find the problem and solve it...

                              I will inform you here if I should manage to find the solution.