0

一个 Connection 正在超时，并且它的开发人员在他的想法列表的底部。

日志有一个友好的：

[6/24/10 6:32:34:032 EDT] 0000000d ThreadMonitor W   WSVR0605W: Thread "WebContainer : 136" (0000c53e) has been active for 719542 milliseconds and may be hung.  There is/are 45 thread(s) in total in the server that may be hung.

代码如下：

    try {
        final URLConnection connection = url.openConnection();
        connection.setConnectTimeout(CONNECT_TIME_SECONDS * 1000);
        connection.setReadTimeout(READ_TIME_SECONDS * 1000);
        is = connection.getInputStream();
        document = builder.parse(is);
    } catch (SAXException e) {
        log.error(e);
        throw new PageContentException(e);
    } finally {
        if (is != null) {
            is.close();
        }
    }

我最好的猜测是 url.openConnection() 正在尝试在连接超时降低到合理的值之前打开连接，但是API中没有任何内容可以告诉我如何以不同的方式进行操作。

关于尝试什么的建议？

4

4 回答 4

2

我会得到线程转储，看看它到底卡在哪里。不要假设。然后你就可以看到为什么它卡在那里了。如果您已经有线程转储，请发布堆栈跟踪。

于 2010-06-24T14:20:38.170 回答
1

我最好的猜测是 url.openConnection() 正在尝试在连接超时降低到合理的值之前打开连接，但是 API 中没有任何内容可以告诉我如何以不同的方式进行操作。

我认为这是可能的情况。IMO，在尝试连接开始后设置连接超时不太可能起作用。

关于尝试什么的建议？

您是否尝试在系统属性中设置“sun.net.client.defaultConnectTimeout”属性？它记录在这里。

于 2010-06-24T14:55:54.437 回答
0

我最好的猜测是 url.openConnection() 试图在连接超时降低到合理之前打开连接。

不，如果是这样的话 URLConnection.setConnectionTimeout() 将完全没有意义，因为没有办法比你更早地调用它。

于 2010-06-25T00:44:49.000 回答
-3

可能是因为“最终”。我不确定你为什么要放在那里，但我认为删除 final 应该会有所帮助。

于 2010-06-24T14:06:56.410 回答