java url连接被拒绝_java - HttpsURLConnection-间歇性连接拒绝错误 - 堆栈内存溢出

我正在通过Java应用程序和HttpsURLConnection实现连接到Web服务。 我打开连接，使用try with resource块打开(并在完成时关闭)输入流和输入流阅读器，然后在finally块中调用connection.disconnect。 该代码在下面，并且大部分时间都有效。

HttpsURLConnection connection = null;

try{

// basic authentication

String encodedAuthString =

DatatypeConverter.printBase64Binary((userName + ":" + password)

.getBytes());

connection = (HttpsURLConnection) url.openConnection();

connection.setRequestMethod("GET");

connection.setRequestProperty("Authorization", "Basic " + encodedAuthString);

//try-with-resource to close connections when complete

try(InputStream in = connection.getInputStream();

InputStreamReader isr = new InputStreamReader(in)){

int numCharsRead;

char[] charArray = new char[1024];

StringBuffer sb = new StringBuffer();

while ((numCharsRead = isr.read(charArray)) > 0) {

sb.append(charArray, 0, numCharsRead);

}

jsonResult = sb.toString();

}

}

catch (Exception e){

throw e;

} finally {

if(connection!= null)

connection.disconnect();

}

但是，多个线程可能在一秒钟内多次调用此代码(尽管实际的包含方法是同步的，因此一次只能有一个线程可以访问该连接)。 在与网络人员合作时，我们发现即使应用程序调用“ connection.disconnect()”，连接也不会立即在服务器上断开连接。 我们在服务器日志中看到了断开连接的调用，但是Java应用程序在服务器完全断开连接之前尝试再次连接，从而导致“连接被拒绝错误”。

无论如何，在再次连接之前通过java强制完全断开连接，或者在调用断开连接时通过服务器设置强制完全断开连接？ 还是一种使它更快发生从而减少出错可能性的方法？ 我可以重试连接，直到成功连接为止，但这似乎是一种hack。

谁能帮助我指出正确的方向？

更新-2013年1月6日-我继续进行调查，发现通过读取tcpdump，我的客户端正在同一端口上连接100个请求，然后在第101个请求上，端口发生了更改，并且我得到了错误。 该连接最终将恢复并开始在新端口上发送和接收请求，但是恢复可能需要一分钟的时间。 我在下面包括了tcpdump。 您可以看到，当客户端在新端口上发送时，目标ip在新端口上返回“ R” eset。 因此，我认为该错误是目的地而不是我的客户的错误导致的，但是由于我对此级别的理解有限，因此我仍在尝试进行验证。

13:20:25.925760 IP DESTINATION_IP.https > CLIENT_IP.53321: P 197809:197846...

13:20:25.925819 IP CLIENT_IP.53321 > DESTINATION_IP.https: . ack 197846 wi...

13:20:25.926393 IP CLIENT_IP.53321 > DESTINATION_IP.https: P 82874:82911(3...

13:20:25.926424 IP CLIENT_IP.53321 > DESTINATION_IP.https: F 82911:82911(0...

13:20:25.928629 IP CLIENT_IP.53322 > DESTINATION_IP.https: S 702514925:702...

13:20:26.005902 IP DESTINATION_IP.https > CLIENT_IP.53321: . ack 82911 win...

13:20:26.008461 IP DESTINATION_IP.https > CLIENT_IP.53322: R 0:0(0) ack 70...

13:20:26.011274 IP DESTINATION_IP.https > CLIENT_IP.53321: P 197846:197883...

13:20:26.011290 IP CLIENT_IP.53321 > DESTINATION_IP.https: R 494623963:494...

13:20:26.011300 IP DESTINATION_IP.https > CLIENT_IP.53321: F 197883:197883...

13:20:26.011305 IP CLIENT_IP.53321 > DESTINATION_IP.https: R 494623963:494...