2016-12-12 9 views
3

This page в документации QuickFix/J делает следующее утверждение: существуетQuickFix/J: отправка сообщения при входе из

Сессии или не подключен счетчик участник. Как только сеанс будет создан, вы можете начать отправлять ему сообщения. Если никто не зарегистрирован, сообщения будут отправляться в момент установления соединения с контрагентом.

Я проверял это поведение с помощью следующих шагов:

  1. Инициализировать новый сеанс QuickFix соединяющий как обычный
  2. прерывание соединения с удаленным сервером так происходит выход из системы для сессии.
  3. Отправить сообщение Разрешить QuickFix восстановить соединение (так, когда происходит Логин для сеанса)

Насколько я могу видеть, сообщение никогда не передается через Session.sendToTarget()

  • .

    Отладка через код, я ударил this line вскоре после получения обратного вызова toApp(). Насколько я вижу, сообщение отправляется только тогда, когда верно isLoggedOn(). В случае неправды (как здесь) никаких альтернативных действий не предпринимается.

    Мое ожидание из приведенной выше документации состоит в том, что QuickFix/J должно каким-то образом помещать сообщение в очередь, чтобы при восстановлении сеанса оно было отправлено. Два вопроса:

    1. Правильно ли эта интерпретация?
    2. Если да, то где и как это реализовано?

    Вот мои параметры подключения для справки:

    [DEFAULT] 
    ConnectionType=initiator 
    LogonTimeout=60 
    ReconnectInterval=30 
    FileStorePath= ... 
    HeartBtInt=30 
    StartTime=22:15:00 
    EndTime=21:55:00 
    UseDataDictionary=Y 
    
    
    [SESSION] 
    BeginString=FIX.4.4 
    SenderCompID= ... 
    TargetCompID= ... 
    PersistMessages=Y 
    ResetOnLogon=Y 
    SessionQualifier= ... 
    SocketConnectHost= ... 
    SocketConnectPort= ... 
    Username= ... 
    Password= ... 
    DataDictionary=config/dict/fix44.xml 
    

    Большое спасибо заранее

  • ответ

    1

    ОК, так что у меня есть очередей сообщений логика работает. Проблема заключалась в том, что ResetOnLogon=Y, по-видимому, испортил количество порядковых номеров.

    +0

    Так вы видите, что пробел заполняется? потому что если вы сбросите номер последовательности при входе в систему, то, вероятно, вы не получите ResendRequest, потому что порядковые номера сбрасываются. Это означает, что ваш тест терпит неудачу, нет? – rupweb

    +0

    Нет, я не видел ни одного зазора. Предположительно, перезагрузка последовательности при входе в систему приводит к выкидыванию любого предыдущего состояния, связанного с сеансом. – user2248785

    +0

    хорошо да я думаю. Итак, насколько я понимаю ваш тест, можно создать новый сеанс и сообщения, хранящиеся в этом сеансе, но затем, как только этот клиент фактически войдет в систему и сбрасывает номера seq, ни одно из сохраненных сообщений на самом деле не будет передано. Это правильно? – rupweb