Я хотел бы уточнить поведение QuickFIX/J (FIX 4.2) в следующем сценарии. Есть две стороны, участвующие в этой связи: QuickFIX/JПоведение очереди сообщений в QuickFIX/J для отключенных клиентов
- клиент инициатор, называемый I.
- Наша акцепторная программа нашей фирмы, которая называется A.
Когда I журналы на , они обмениваются FIX сообщения с тегом 35=A. Как только соединение установлено, I начинает подавать заказы. Там может быть точкой, однако, где I отсоединяется неожиданно, в какой момент решает отправить отменяет для всех открытых порядков I (это справедливо, потому что понятия не имеет, почему я не удалось или когда I вернется живым).
Обратите внимание, что вся эта отмена-на-разъединитель процедура инициируется и обрабатывается Одна лишь - он получает инициировано onLogout(...) способа А «ы и обрабатывается его нормальными механизмами управления заказами. Одно сообщение 35=F генерируется для каждого открытого ордера I, а ExecutionReport (35=8) генерируется при каждом успешном отмене.
Когда я возвращается живым, эти ExecutionReport s должны быть доставлены в я как-то так, что становится известно все свои предыдущие заказы были отменены. У меня сложилось впечатление, что реализация очереди сообщений QuickFIX/J обрабатывает это без помощи на уровне приложения. Все сообщения QuickFIX предоставляются для доставки контрагентам (http://permalink.gmane.org/gmane.comp.finance.quickfix.devel/169).
Вопреки моему пониманию, однако, не ExecutionReport s были не показаны в QuickFIX бревен «s, или доставлены I когда я Reconnected, в результате я, чтобы не знать, что его предыдущие заказы есть был отменен. Я заметил, что запись не происходит из-за следующий исходный код sendRaw(Message message, int num) метода Session в QuickFIX/J:
/**
* Send the message
*
* @param message is the message to send
* @param num is the seq num of the message to send, if 0, the next expected sender seqnum is used.
* @return
*/
private boolean sendRaw(Message message, int num) {
...
} else {
try {
application.toApp(message, sessionID);
} catch (final DoNotSend e) {
return false;
} catch (final Throwable t) {
logApplicationException("toApp()", t);
}
messageString = message.toString();
if (isLoggedOn()) { // happens only if session is connected
result = send(messageString); // logging happens within "send"
}
}
...
}
Сеанс не вошедшем в то время как ExecutionReport сообщений были генерируется для отменяет инициирована I-х отключите, и поэтому он никогда не попал в send(messageString);, и никаких протоколов не произошло. Я считаю, что никакое сообщение не попало в очередь (на основании того, что I не получает сообщений, когда он возвращается в живых) по той же причине.
Наша фирма сделала множество реализаций, основанных на убеждении, что QuickFIX/J гарантирует, что все сообщения будут доставлены без потерь, но мое наблюдение за сценарием выше говорит иначе.
Какова очередь сообщений QuickFIX/J в этом сценарии, когда сеанс не вошел в систему? Должен ли он отправлять сообщения в очередь независимо от того, будет ли он отправлен после того, как сеанс снова станет доступным в будущем, или остановите очередь в течение продолжительности, пока сессия не будет работать?
Вы можете попробовать список рассылки QF/j для этого, если никто здесь не отвечает. –
«Однако может возникнуть вопрос, когда я неожиданно разъединяюсь, после чего A решает отправить отмену всех открытых ордеров I [...]». Это звучит ужасно. Просто потому, что есть сетевая проблема, например, в течение 15 минут, вы отменяете все заказы ??? Извините, что так, но это звучит смешно. Что за этим стоит? Какое реальное деловое объяснение существует для этого требования? –
@ GrantBirchmeier Спасибо за отзыв. Фактически мы подтвердили, что «35 = 8» и «150 = 4» пришли к инициатору от акцептора при повторном подключении. Я так и не смог это обнаружить. – ylee