Как исследовать случайный сброс на порте клиента TCP, подключенном через петлевой интерфейс к серверу
Для уничтожения процесса, который связан с несколькими процессами, необходимо уничтожить это при помощи идентификатора процесса, связанного с тем процессом.
Получить идентификатор процесса того выполненного процесса Java
ps -A |grep java
вывод этой команды даст список процессов Java, работающих на Вашей системе. Запишите идентификатор Процесса (PID) того процесса, кого Вы хотите уничтожить и выполнить
kill -9 PID
] Просто хотим завершить данный поток принятым решением в отсутствие исправления первопричины, которая, как я полагаю, находится в реализации стека Fedora 4 TCP. В качестве решения я просто ввел немедленную попытку повторного подключения в случае, если сбой произошел из-за ETIMEDOUT и использовался протокол IPV6. Это исправило проблему для меня и моей команды навсегда с возможным риском дополнительной 3-х минутной задержки в сообщении об ошибке при любом другом нарушении соединения, приводящем к ETIMEDOUT. Это не является реальным/идеальным решением проблемы, но заставляет нас двигаться дальше... так как это единственное, что влияет на наш автоматизированный набор тестов, а не на то, что он не будет отправлен клиенту. Я надеюсь, что в конце концов кто-нибудь, кто достаточно хорошо знает реализацию стека Федора 4 tcp/ip, решит эту загадку навсегда[
].