ошибка с ++ fastfix для отправки

У меня возникла непредвиденная проблема с клиентским приложением fastfix C++ с использованием FIX 4.4. Я формирую marketdatarequest и заполняю его, а затем вызываю send, который возвращает true. Сообщение не найдено в файлах сообщений или журналов событий. Кажется, что ошибка не сообщается - что может случиться?ошибка с ++ fastfix для отправки

FIX44::MarketDataRequest request(FIX::MDReqID(tmp) 
     , FIX::SubscriptionRequestType('1') 
     , FIX::MarketDepth(depth)); // 0 is full depth 
FIX::SubscriptionRequestType subType(FIX::SubscriptionRequestType_SNAPSHOT); 
FIX44::MarketDataRequest::NoRelatedSym symbolGroup; 
symbolGroup.set(FIX::Symbol(I.subID)); 

request.addGroup(symbolGroup); 

FIX::Header &header = request.getHeader(); 
header.setField(FIX::SenderCompID(sessionSenderID)); 
header.setField(FIX::TargetCompID(sessionTargetID)); 


if (FIX::Session::sendToTarget(request) == false) 
    return false;

Моего FixConfig выглядит как:

[DEFAULT] 
HeartBtInt=30 
ResetOnLogout=Y 
ResetOnLogon=Y 
ResetOnDisconnect=Y 
ConnectionType=initiator 
UseDataDictionary=Y 
FileLogPath=logs 
[SESSION] 
FileLogPath=logs 
BeginString=FIX.4.4 
DataDictionary=XXXXX 
ConnectionType=initiator 
ReconnectInterval=60 
TargetCompID=tCompID 
SenderCompID=sCompID 
SocketConnectPort=123456 
SocketConnectHost=XX.XX.XXX.XX 
SocketConnectProtocol=TCP 
StartTime=01:05:00 
EndTime=23:05:30 
FileLogPath=logs 
FileStorePath=logs 
SocketUseSSL=N

спасибо за любую помощь, Марку

источник

2014-10-15 Mark Rousseau

'SocketConnectPort = 123456' Действительно ли это порт, который вы используете? Самый большой номер порта - * 65535 *. Удалось ли вам создать сеанс с вашим контрагентом и войти в систему? Проверьте, можете ли вы вообще войти в систему, это должен быть ваш первый шаг, чтобы подтвердить, можете ли вы отправлять какие-либо дополнительные сообщения. – DumbCoder

Порт является владельцем места - мой клиент может без проблем подключиться, войти в систему и сердцебиение. –

Я, наконец, решил это на ночь - я отправлял эти сообщения до завершения обработки входа в систему. Перемещение логики в обратный вызов onLogon разрешило проблему. –

-1

Марка, только несколько заметок на самом деле не связаны с вашим вопросом, но которые вы можете нашли полезными:

Вам не нужно явно указывать TargetCompId/SenderCompId для каждого сообщения, двигатель будет сделайте это за вас.
Не помещайте логику в обратные вызовы (как, например, с подпиской на рыночные данные в onLogon). Лучше создайте дополнительный поток, который будет потреблять события от слушателя, принимать решения и принимать меры.

источник

2014-10-21 04:12:20 rimas

Не нисходящий, но они должны идти в комментариях, а не в качестве ответа. – DumbCoder

Спасибо, rimas, Мне нравится, что обратный вызов переключается на поток, но он вызывает дополнительные вопросы для меня. Каков жизненный цикл сообщений, переданных в обратном вызове? Разве они уничтожаются, когда обратный вызов восстанавливает контроль? Если это так, мне пришлось бы сделать копию данных перед тем, как оставить обратный вызов, и передать эту копию в рабочий поток (ы) рабочего стола. –

Да, они будут уничтожены вне обратного вызова. Я предлагаю сохранить логику вне любого из них из-за проблемы с производительностью. – rimas

ответ

Смежные вопросы