После входа в систему отправка ResendRequest

Мой механизм исправления клиента подключается к механизму исправления сервера с помощью quickfix4j.

Механизм исправления сервера работает с воскресенья 1:00 до пятницы 17:00.

Это моя конфигурация инициатора


    [default]
    FileStorePath=some path
    ConnectionType=initiator
    SocketConnectHost=remoteserver
    StartTime=00:00:00
    EndTime=00:00:00
    HeartBtInt=30
    ReconnectInterval=10
    ResetOnDisconnect=N
    ResetOnLogout=N
    ResetOnLogon=N
    SocketUseSSL=Y
    ForceResync=Y

    [session]
    BeginString=FIX.4.4
    SocketConnectPort=9878
    SenderCompID=TestSender
    TargetCompID=TestTarget
    SendRedundantResendRequests=N
    UseDataDictionary=Y
    DataDictionary=FIX44.xml
    SessionName=TRADING
    ValidateUnorderedGroupFields=N
    ValidateIncomingMessage=N

Мой выход из сеанса в 19:00: EST (то есть 00:00:00 UTC). Это верно.

Снова механизм исправления клиента отправляет запрос на вход и получает ответ на вход с сервера. Сразу после ответа на вход я вижу resendRequest, который делает мой механизм исправления (35 = 2).

Я заметил, что мой запрос на вход 35=A имеет порядковый номер 0, но результат сервера намного выше.

Из-за этого движок исправления клиента отправляет ResendRequest.

НУЖНО ли мне обновить мою конфигурацию, чтобы решить эту проблему?


quickfix fix-protocol quickfixj
person user2672763    schedule 04.01.2016    source источник
comment
Узнайте, что ваш контрагент ожидает от вас с порядковыми номерами при выходе из системы/входе в систему, и соответствующим образом настройте свой ResetOnLogout. Я ожидаю, что у вас ResetOnLogout будет равно Y   -  person TT.    schedule 04.01.2016
comment
Согласен с тобой. Я проверю это.   -  person user2672763    schedule 04.01.2016
comment
Лучше всего начать новый вопрос StackOverflow для нового вопроса, а не редактировать его в текущем вопросе. В противном случае это становится слишком хаотичным.   -  person TT.    schedule 04.01.2016
comment
Сделанный. Спасибо за ваше предложение.   -  person user2672763    schedule 04.01.2016
comment
К вашему сведению, это QuickFIX/J, а не quickfix4j. Я исправил ваш заголовок.   -  person Grant Birchmeier    schedule 04.01.2016
comment
См. Должны ли вопросы включать «теги» в свои заголовки? , где консенсуса нет, не должны!   -  person    schedule 04.01.2016
comment
Удачи с подсказкой, которую я дал?   -  person TT.    schedule 05.01.2016
comment
ResetOnLogout не поддерживается механизмом исправлений сервера. Но они попросили использовать ResetOnLogon=Y, но в этом случае мы не сможем запросить resendMessages. Я делаю сеанс клиента таким же, как сеанс сервера (длиной в неделю), чтобы не было сброса последовательности в середине недели, и в случае любого отключения мы можем запросить повторную отправку сообщения. Думаю, это был бы лучший подход.   -  person user2672763    schedule 05.01.2016
comment
Повторная отправка сообщений не является чем-то, что вам нужно делать самостоятельно, сеансовый уровень QuickFix сделает это, если этого требует протокол FIX (т. е. пробелы в идентификаторе последовательности сообщений). Также: прочитайте эту тему на Meta.StackExchange в комментариях. Я не был проинформирован о вашем комментарии, так как вы не начали свой комментарий с @TT.   -  person TT.    schedule 06.01.2016
comment
@TT: Ты прав. Повторный запрос не выполняется вручную. Но когда у нас есть ежедневный сеанс, а сервер имеет недельный сеанс, несоответствие последовательности обнаруживается в начале каждого клиентского сеанса (последовательность сбрасывается до нуля). Это приводит к повторной отправке сообщения. Я бы позаботился об ответах, используя @.   -  person user2672763    schedule 06.01.2016
comment
Удачи тебе в настройке, дружище =)   -  person TT.    schedule 06.01.2016

Ответы (1)


arrow_upward
0
arrow_downward

Ваши Start/EndTime и Start/EndDay всегда должны совпадать с таковыми на стороне сервера.

person Dan Corneanu    schedule 31.01.2016