Обнаружение потери соединения для исправления шлюза? (Быстрая починка)

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

Быстрый способ - заглянуть в код и проверить, где обрабатывается закрытие сокета и какой путь выполняется, когда это происходит.

Лучший способ решить эту проблему, вероятно, - уменьшить интервал сердцебиения, чтобы вы знали об этом раньше. Я не знаю сообщений, которые срабатывают при потере TCP-соединения, но я не думаю, что QuickFix также отслеживает события ОС. Хотя, если бы такое сообщение было, оно, скорее всего, прошло бы через событие fromAdmin.

Вы разместили свой вопрос в QuickFix DL?

Сам TCP имеет собственный механизм проверки пульса, называемый SO_KEEPALIVE. Проблема в том, что интервал по умолчанию для этого контрольного сигнала может достигать 2 часов. Это настраивается на уровне ОС. Так что теоретически вы можете включить SO_KEEPALIVE, настроить разумный интервал подтверждения на уровне ОС и быть счастливым. Однако, поскольку, как уже говорилось, это очень зависит от ОС, большинство приложений предпочитают реализовывать тактовые импульсы на уровне приложений, и FIX не является исключением. Уменьшение интервала FIX heartbeat - это правильный путь, особенно если вы полагаетесь на отмену при отключении, и дополнительные секунды необнаруженной потери соединения могут привести к нежелательному исполнению приказов. Шлюз FIX, реализованный поверх любого механизма исправлений, должен поддерживать конфигурацию тактового сигнала "из коробки". Взгляните, например, на CoralGateway. (Отказ от ответственности: я один из разработчиков CoralGateway)