Java HttpURLConnection InputStream.close () зависает (или работает слишком долго?)

Во-первых, немного предыстории. Есть рабочий, который раскрывает / разрешает кучу коротких URL:

http://t.co/example -> http://example.com

Итак, мы просто следим за перенаправлениями. Вот и все. Мы не читаем данные из соединения. Сразу после того, как мы получили 200, мы возвращаем конечный URL и закрываем InputStream.

Теперь сама проблема. На рабочем сервере один из потоков преобразователя зависает внутри вызова InputStream.close():

"ProcessShortUrlTask" prio=10 tid=0x00007f8810119000 nid=0x402b runnable [0x00007f882b044000]
   java.lang.Thread.State: RUNNABLE
        at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
        at java.io.BufferedInputStream.skip(BufferedInputStream.java:352)
        - locked <0x0000000561293aa0> (a java.io.BufferedInputStream)
        at sun.net.www.MeteredStream.skip(MeteredStream.java:134)
        - locked <0x0000000561293a70> (a sun.net.www.http.KeepAliveStream)
        at sun.net.www.http.KeepAliveStream.close(KeepAliveStream.java:76)
        at java.io.FilterInputStream.close(FilterInputStream.java:155)
        at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.close(HttpURLConnection.java:2735)
        at ru.twitter.times.http.URLProcessor.resolve(URLProcessor.java:131)
        at ru.twitter.times.http.URLProcessor.resolve(URLProcessor.java:55)
        at ...

После краткого исследования я понял, что skip() вызывается для очистки потока перед его отправкой обратно в пул подключений (если включена поддержка активности?). До сих пор не понимаю, как избежать этой ситуации. Более того, я сомневаюсь, что в нашем коде плохой дизайн или есть проблема в JDK.

Итак, вопросы:

1. Можно ли избежать зависания на close()? Например, обеспечьте разумный тайм-аут.
2. Можно ли вообще избежать чтения данных из соединения? Помните, мне нужен только конечный URL. На самом деле, я думаю, я вообще не хочу, чтобы skip() назывался ...

Обновление:

KeepAliveStream, строка 79, close() метод:

    // Skip past the data that's left in the Inputstream because
    // some sort of error may have occurred.
    // Do this ONLY if the skip won't block. The stream may have
    // been closed at the beginning of a big file and we don't want
    // to hang around for nothing. So if we can't skip without blocking
    // we just close the socket and, therefore, terminate the keepAlive
    // NOTE: Don't close super class
    try {
        if (expected > count) {
        long nskip = (long) (expected - count);
        if (nskip <= available()) {
            long n = 0;
            while (n < nskip) {
            nskip = nskip - n;
            n = skip(nskip);} ...

Мне все больше и больше кажется, что в самом JDK есть ошибка. К сожалению, воспроизвести это очень сложно ...