Thread getting locked at “www.protocol.http.HttpURLConnection”

Question

My threads are getting locked while calling

new URL(url).openConnection();

A part of thread dump is:

sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195)
    - locked <0x00000007056a2498> (a sun.net.www.protocol.http.HttpURLConnection)
    at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)

which appears to be locked at

"JakartaHttpHandler-http-timeout-pool-12-thread-1" daemon prio=10 tid=0x0000000046bb6800 nid=0x162 waiting on condition [0x00000000431b7000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000007521c68b8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)

In the end heap details say,

compacting perm gen  total 41408K, used 41295K [0x00000007fae00000, 0x00000007fd670000, 0x0000000800000000)
   the space 41408K,  99% used [0x00000007fae00000, 0x00000007fd653e58, 0x00000007fd654000, 0x00000007fd670000)

Threads do not proceed without throwing any exception.

Firstly, I am planning to change the -XX:MaxPermSize. Is there any other thing I can do?

I am sure, people must have faced this exception.

Thanks in advance.

Answer 1

Go a bit up in the stack trace. Your application is probably opening a connection an external website like for example SpringFramework.org possibly to get XSDs.

See what those websites are and check if they can be accessed from that machine where your application is deployed using wget.

Answer 2

Is it possible you're actually stuck at a "connect()" call further down?

The code you're looking for is probably closer to:

    HttpURLConnection connection = new URL(url).openConnection();
    connection.setConnectTimeout(10000);
    connection.setReadTimeout(10000);
    connection.connect();

This will create the connection object, set it to a 10s connect timeout (trying to make a connection to the remote host) and a 10s read timeout (the amount of time it can spend waiting for a response). The first could conceivably need to be higher if you're on a very slow network. The second might need to be bumped up if your service takes awhile to respond due to long operations on some resources. In any case, the default is infinity and that's probably not a good idea for any production system.