Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

246
Views
Stucked thread on SOAP webservice call

I have a stuck thread in a Tomcat container, I would like to find the cause to avoid this problem.

Using jstack I have found it is stuck after a SOAP webservice call:

pool-2-thread-1" #27 prio=5 os_prio=0 tid=0x00007fd2315ce800 nid=0x39 runnable [0x00007fd2415d2000]
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
    at java.net.SocketInputStream.read(SocketInputStream.java:171)
    at java.net.SocketInputStream.read(SocketInputStream.java:141)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
    at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
    - locked <0x0000000087eb10e0> (a java.io.BufferedInputStream)
    at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:735)
    at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
    - locked <0x0000000087eb1138> (a sun.net.www.protocol.http.HttpURLConnection)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
    - locked <0x0000000087eb1138> (a sun.net.www.protocol.http.HttpURLConnection)
    at java.net.URL.openStream(URL.java:1045)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.createReader(RuntimeWSDLParser.java:999)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.resolveWSDL(RuntimeWSDLParser.java:400)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:231)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:209)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:178)
    at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:364)
    at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:322)
    at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:231)
    at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:212)
    at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:208)
    at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:119)
    at javax.xml.ws.Service.<init>(Service.java:77)

Which timeout is missing in the configuration? I'm using the standard options.

over 4 years ago · Santiago Trujillo
1 answers
Answer question

0

Your client tries to download the WDSL file of the SOAP service from a remote URL. HttpURLConnections have by default an infinite socket read timeout and an infinite connect timeout. In your case the connection seems to be stuck, while reading from the server. Since the read timeout is infinite, you are stuck forever or at least until the connection is reset (e.g. by a router or the server).

As already mentioned in one of the comments, the default timeouts can be configured through the system properties sun.net.client.defaultReadTimeout and sun.net.client.defaultConnectTimeout (as documented here). You could set these properties also at runtime, but you would have to do this before the properties are read. Unfortunately, the properties are read only once when the internal NetworkClient class is loaded. I haven't tried it out, but it is very unlikely that you will be able to set the properties within a Tomcat container, before this class gets loaded. If you should have a chance to change the start script of the Tomcat, I would heavily recommend to set explicit timeouts (especially in case of a production setup).

Setting explicit timeouts, is in general a good approach. But timeouts will only solve the described symptom, but not your actual problem: Your SOAP client relies on the successful download of a WSDL file from a remote location. Instead of downloading the WSDL file from a remote location, you could load it from a local resource. There are two possible ways to do this:

A) If you should have access to the (generated) client code, you could replace the remote URL of the WSDL location with the URL of a resource file on your classpath. See this answer for an example.

B) If manual adaptation of the client code isn't an option, you can use a catalog file, as documented here.

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!