QuickFix Sequence Reset не работает - PullRequest
Новая
       31

QuickFix Sequence Reset не работает

1 голос
/ 05 января 2012

Я работаю над QuickFix / J (FIX 4.2), чтобы отправлять заказы в механизм FIX акцептора.В основном мне нужна помощь по двум учетным записям:

  1. Когда я впервые пытаюсь установить соединение с акцептором, акцептор отклоняет начальные запросы входа в систему, говоря «Msg Seq No too Low».После этого мой инициатор продолжает увеличивать исходящий порядковый номер на единицу, а когда этот послед.и нет.Ожидается совпадение двигателя акцептора, я получаю стабильное соединение.Чтобы ускорить этот процесс, я начал извлекать ожидаемый результат.нет.из сообщения об отклонении, отправленного механизмом акцептора и измененного исходящей последовательности №.для моего двигателя, используя 

    session.setNextTargetMsgSeqNum(expectedSeqNo).

    Однако позже, если мой двигатель найдет входящую последовательность, нет.выше, чем ожидалось, он отправляет запрос на повторную отправку.В ответ другая сторона отправляет сообщение сброса последовательности (35 = 4, 123 = Y).Теперь после получения этого сообщения, входящий seq нет.для моего двигателя должен быть автоматически установлен тот, который он получил от Seq Reset msg.Но этого не происходит, и мой движок продолжает запрашивать повторный запрос сообщений без изменений во входящем seq no.Интересно, что я нашел, что это работает, когда я не изменяю явно исходящий seq no во-первых (используя setNextTargetMsgSeqNum).

    Почему мой движок не показывает ожидаемое поведение при получении сообщения «Сброс последовательности»?

  2. Я разговаривал с другой стороной, и у меня не будет ResetOnLogon = Y вих конфигурация.Поэтому каждый раз, когда запускается мой движок, он часто отправляет запрос на вход с последующим номером.ниже, чем ожидалось (начинается с 1).Есть ли лучший способ быстро установить соединение?Как я могу как-то заставить свой двигатель использовать последовательность №.возобновить с того момента, прежде чем он упал?Каким должен быть идеальный подход?

Так что теперь я сохраняю сообщения в файле, который заботится о порядковых номерах.Тем не менее, снова беспокоит то, что мой механизм инициатора быстрого исправления не отвечает на сообщения сброса последовательности.Теперь нет никаких обратных вызовов администратора.

Я замечаю, что почти всегда не происходит никакого ответа на сообщение сброса последовательности, когда я подключаюсь к акцептору с одного сервера, а затем закрываю этот сеанс и использую другой сервер для соединения с акцептором, используя тот жеидентификатор сессии.Как только вход в систему будет принят, я ожидаю, что все будет работать нормально.Однако, в то время как другой механизм отправляет сброс последовательности на определенный номер (в основном заполнение пропуска), мой механизм исправлений не отвечает на него, то есть он не сбрасывает ожидаемый порядковый номер и продолжает отправлять запросы на повторную отправку получателю.Любая помощь будет принята с благодарностью!

1 Ответ

10 голосов
/ 06 января 2012

Для обычного использования сеанса FIX вы настраиваете время начала и окончания сеанса и позволяете механизму управлять порядковыми номерами. Например, если ваша сессия активна с 8:00 до 16:30, то QuickFIX / J автоматически сбросит исходящий и входящий порядковый номер на 1 при первом запуске двигателя после 8:00 (или в 8: 00:00, если двигатель уже запущен в это время).

(Вопрос № 1). Вы правы, что ваш двигатель должен использовать новый входящий порядковый номер после сброса последовательности. Учитывая, что это работает правильно для тысяч пользователей QuickFIX / J, подумайте о том, что вы можете сделать, чтобы изменить это поведение. Например, есть ли у вас ответное сообщение администратора и может ли оно вызывать исключения. Вы просматривали свои файлы журналов, чтобы увидеть, есть ли какие-нибудь подсказки там?

(Вопрос № 2). Если вы используете постоянный MessageStore (FileStore, JdbcStore и т. Д.), Ваш исходящий порядковый номер будет доступен при перезапуске.

...