Инициатор quickfixj вручную повторно отправляет сброс в seqnum при входе в систему

Question

У меня есть инициатор quickfixj, подключающийся к принимающему поставщику и получающему сообщения.Я храню сообщения об исправлениях в буфере, который обрабатывается потоком.Чтобы не потерять сообщение в случае сбоя с сообщением в буфере, я обработал последний seqnum и планирую отправить сообщение повторной отправки для следующего seqnum на моей стороне при повторном подключении.Я знаю, что лучшим решением было бы сохранить сообщения до того, как я их получу, но цель состоит в том, чтобы избежать доступа к БД в вызове onMessage.Я не нашел ни одного примера, как это можно сделать, повторно отправив запрос для определенного seqnum.Должен ли я просто перегрузить сообщение для входа и отправить seqnum?У кого-нибудь есть пример?

Answer 1

Я полагаю, что вы уже синхронизированы в соответствии с последним потоком Если в системном сообщении произойдет сбой quickfixj, я потеряю текущее сообщение? .

QuickFixJ управляет двумя порядковыми номерами:

1. SenderSequenceNum: порядковый номер, используемый при отправке сообщений.
2. TargetSequenceNum: порядковый номер, ожидаемый для получения.

Таким образом, у вас есть две опции:

Вариант 1. Обработка полученных сообщений в потоке обратного вызова QuickfixJ onMessage ().Так что в случае исключения порядковый номер не увеличивается.И QuickFixJ автоматически отправляет запрос на повторную отправку при получении следующего сообщения об исправлении, поскольку он обнаружит разрыв последовательности.

Вариант 2. Сохранение порядкового номера, который вы успешно обработали.В случае сбоя при перезапуске вы можете установить ожидаемый порядковый номер приема, используя:

Session.lookupSession(session_).setNextTargetMsgSeqNum();

Поэтому, если вы получите порядковый номер выше этого, QuickfixJ автоматически отправляет запрос на повторную отправку.

Примечание. Не изменяйте порядковый номер отправителя, тогда другая сторона получит порядковый номер ниже ожидаемого и может вызвать отключение.