Сертификация торговой системы

У нас соединение одно. Если мы действительно два раза открываем что-то - это ошибка, надо открывать один раз.

Еще на ртс возникли вопросы на счет обработки lifeNum, переспросил что конкретно не нравится, завтра напишут. У нас точно все правильно написано? Из документации:

«Безбазовый» клиент должен изменить номер жизни с помощью вызова P2TableSet-> SetLifeNumToIni и переоткрыть поток вручную. Посмотрел код, не заметил чтобы мы переоткрывали потоки, или это както спрятано?

Еще на ртс возникли вопросы на счет обработки lifeNum, переспросил что конкретно не нравится, завтра напишут. У нас точно все правильно написано? Из документации:

«Безбазовый» клиент должен изменить номер жизни с помощью вызова P2TableSet-> SetLifeNumToIni и переоткрыть поток вручную. Посмотрел код, не заметил чтобы мы переоткрывали потоки, или это както спрятано?

Т.к. конкретной проблемы нет, то ответить всё ли у нас правильно невозможно. Событие OnStreamLifeNumChanged у нас обрабатывается

А остальные проблемы решены сейчас?

Alexander Mukhanchikov: А остальные проблемы решены сейчас?

Я в своей версии программы разбил получение данных на три потока, и это помогло, очереди значительно снизились, этот вопрос у ртс отпал. Также вроде через клиринг прохожу нормально. Но у меня при работе робота стала вылетать иногда ошибка "не могу отменить заявку с номером таким-то", и не ясно, это косяк моего торгового алгоритма, или тех изменений, что я вносил чтобы через клиринг проходить. Короче, там явно придется еще повозиться, чтобы все аккуратно написать и все ошибки выловить

FiNick: стала вылетать иногда ошибка "не могу отменить заявку с номером таким-то", и не ясно, это косяк моего торгового алгоритма, или тех изменений, что я вносил чтобы через клиринг проходить.

Ошибка говорит что заявка уже снята или исполнена. Тоесть, снять ее уже не получится. Обычно бывает из-за того, что или алгоритм неправильно работает, или данные не успевают прийти. Второе - это нормальная ситуация. Нужно разруливать подобное.

Всем привет! Написал робота скальпера для плазы и использованием библиотеки Stock#. Соответственно на демо-счете адекватно потестить не получается, пришлось проходить сертификацию. Отправил им логи после работы программы, вот что они написали:

По логу есть два вопроса:

1. У вас растет очередь сообщений, и с этим надо бороться: 2012-01-17 11:40:31.582;p2mq-cli;;New message added to recvList. Size: 73 2012-01-17 12:06:34.368;p2mq-cli;;New message added to recvList. Size: 2140 2012-01-17 14:46:50.340;p2mq-cli;;New message added to recvList. Size: 279 Бороться можно например путем получения реплики в нескольких соединениях, каждое открывающееся в отдельном треде и со своим циклом выборки.

2. Как вы обрабатываете событие смены номера жизни для агрегированных потоков и для FUT/OPTCOMMON ? Т.к. обрабатывает их наверняка библиотека сток-#, то предлагаю эксперимент:

• обнулить номер жизни в используемых orders_aggr.ini, fut/opt_common.ini или в forts_scheme.ini - смотря откуда схему берете
• запустить свое приложение один раз, выключить
• запустить второй раз, выключить
• прислать логи П2 за оба запуска.

Т.к. я пользуюсь библиотекой, как она есть, прошу специалистов помочь в решении поставленных вопросов. Буду очень вам благодарен.

Какая помощь нужна? По первому вопросу - проблема известна, давно писали уже об этом. Как решать - тоже понятно. FiNick вроде сделал, но можете ему помочь в этом. Его изменения пока у него локально хранятся.

По второму - вроде всё расписано как надо делать. Как обрабатываем - смотрите OnStreamLifeNumChanged.

библиотека сток-#

Что за библиотека? Ссылкой поделитесь?[biggrin]

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

Проблема в том, что то что у нас было написано для этого (Save/LoadRevision) у меня вот не работает: делается LoadRevision и у меня только два инструмента в списке, и только по этим инструментам сделки подгружаются, как ремонтировать не знаю