java.net.ConnectException/java.net.ConnectException в зависимости от нормального запуска или в режиме отладки

Question

Привет пытаюсь отправить бинарное сообщение на сервер с портом IP и:

192.168.2.101:10001

Разъем возобновляется каждые 50 сообщений.

Если я запускаю приложение, как правило, я получаю java.net.ConnectException в строке 5, хотя я могу пинговать и telnet-сервер.

Если я отлаживаю приложение, я получаю исключение java.net.SocketException в другой строке (11), также иногда первое сообщение, кажется, проходит без ошибок.

private void sendMessage(String message, int relaisId, long timestamp) { 

    try { 
     if (connCount > 50) { 
      s = new Socket(ip, port); //RUN NORMALLY: java.net.ConnectException: Connection refused: connect 
      connCount=0; 
     } 
     outputStream = s.getOutputStream(); 

     outputStream.write(message.getBytes()); 
     outputStream.write(new byte[]{0});//DEBUG: java.net.SocketException: Connection reset by peer: socket write error 
     outputStream.flush(); 
     connCount++; 
    } catch (UnknownHostException ex) { 
     logger.error("Host not found: " + ip + ":" + port, ex); 
     connCount=51; 
     retryMessage(message, relaisId, timestamp);// basically sleep 3s then call sendMessage 
    } catch (IOException ex) { 
     logger.error("Error at Relais No. " + relaisId + ": " + ip + ":" + port, ex); 
     connCount=51; 
     retryMessage(message, relaisId, timestamp); // basically sleep 3s then call sendMessage 
    } finally { 
     try { 
      if (connCount > 50 && s != null) { 
       s.close();      
      } 
     } catch (IOException ex) { 
      logger.error("IOException", ex); 
     } 
    } 
} 

помощь или инструменты анализа очень ценятся :)

Answer 1

Я нашел решение. В моей программе разные потоки отправляют сообщения внешним аппаратным компонентам по заданным IP-адресам и портам. Эта ошибка возникла из-за того, что нить случайно инициировалась дважды с тем же IP-адресом и портом, что привело к конфликтам синхронизации при использовании одного и того же сокета.

Еще более странным было то, что эта ошибка начала возникать постоянно при изменении серверной машины, прежде чем она была только там, и мы думали, что это был шум в сетевой связи.

Надеюсь, что это поможет любому в будущем :)