тестирование Socket # Connect тайм-аут в Java

Question

Недавно я исследовал рабочую проблему с Java-приложением.Есть два процесса, processA и processB, работающие на одном хосте.

processA подключает сокеты к процессуB.ProcessB перезапустился, но каким-то образом после перезапуска все вызовы Socket # connect из processA заблокированы (на несколько минут).

Я думаю, что у processB каким-то образом был сломан сокет (получая SYN, но никогда не отвечал).Проблема устранилась сама собой (автоматический перезапуск), поэтому я не смог перехватить tcp-трафик, чтобы быть уверенным.

Я знаю, что наш сокет-клиент должен иметь короткий тайм-аут при соединении (по умолчанию os кажется огромным в этом случае).

Мне просто было интересно, как написать неудачный тест для моего сокет-клиента.

Можно ли сделать что-то вроде этого:

@Test
public void testClientTimeoutOnConnectionAttempt() {
    startBrokenSocketServer()
    assertConnectionExceptionWithinOneSecond(myClient);
}

Я понял, какчтобы вручную создать эти условия, используя ipfw и netcat.

 sudo ipfw add 100 drop ip from 127.0.0.1 6969 to any
 nc -l -p 6969

nc прослушивал 6969 (не позволяя ОС отправлять rst, ack), а ipfw препятствовал моему процессу java получать любой syn_ack от nc.

Без тайм-аута в вызовах Socket # connect прошло 75 секунд (на Mac OS) перед исключением SocketException.Если я укажу тайм-аут, он потерпит неудачу раньше.

Клиент, который мне нужно изменить, принадлежит другой команде.Я хотел бы отправить им исправление вместе с автоматизированным тестом, который демонстрирует это.Есть идеи как это сделать?

Answer 1

Мне было просто интересно, как написать неудачный тест для моего сокет-клиента.

Я не думаю, что это возможно в Java. Вы, конечно, можете симулировать множество функциональных возможностей netcat, но не ipfw. Я даже не уверен, что это возможно в C, если вы не сделаете несколько специфичных для ОС вызовов ядра.

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

Хромой ответ, но другого пути я не вижу.