Оставшиеся задачи до версии бета
Atom Ответить
07.05.2011



  1. Нужно доделать потоки с заявками, сделками (собственными и тиковыми). Сейчас через потоки заполняются только инструменты, портфели, стаканы и позиции.
  2. PlazaStreamManager сейчас создает отдельные потоки для каждного стрима. Расточительно по ресурсам. Лучшем переделать на ThreadPool. И да, кто может мне объяснить в чем смысл всех этих ProcessMessage?
  3. Логику PlazaTableSerializer лучше перекинуть в PlazaSchemaParser. И да, можно ли построить логику PlazaSchemaParser на основе IniConfigParser?


Кто что сделает?

Теги:


Спасибо:




43 Ответов
1 2  >
aspirant

Фотография
Дата: 07.05.2011
Ответить


Mikhail Sukhov Перейти
PlazaStreamManager сейчас создает отдельные потоки для каждного стрима. Расточительно по ресурсам. Лучшем переделать на ThreadPool.

Займусь.

Mikhail Sukhov Перейти
И да, кто может мне объяснить в чем смысл всех этих ProcessMessage?

Это такой протокол. См. стр. 7 P2ClientFate.doc:

Цитата:
5.2. Принципы работы с соединениями в API
Работа с соединениями производится по стандартному шаблону:
• Создание объекта IP2Connection.
• Вызов метода Connect — при его успешном завершении устанавливается локальное соединение с роутером.
• Запуск бесконечного цикла, в котором происходит вызов функции ProcessMessage для соединения.


Mikhail Sukhov Перейти
Логику PlazaTableSerializer лучше перекинуть в PlazaSchemaParser.

PlazaSchemaParser не используется вообще. Я его оставил, потому что уже сделал и жалко было выкидывать готовый, хотя и сырой, парсер ini-файлов потоков репликации. Может быть оставим PlazaTableSerializer и выкинем PlazaSchemaParser?

Mikhail Sukhov Перейти
И да, можно ли построить логику PlazaSchemaParser на основе IniConfigParser?

Наверное, да. Но можем усложнить жизнь. Синтаксис в ini-файлов потоков репликации немного отличается (чуть сложнее). Может быть оставим, как есть?


Mikhail Sukhov Перейти
Кто что сделает?

Таким образом беру 2 и 3.
Спасибо:

aspirant

Фотография
Дата: 07.05.2011
Ответить


aspirant Перейти
Mikhail Sukhov Перейти
PlazaStreamManager сейчас создает отдельные потоки для каждного стрима. Расточительно по ресурсам. Лучшем переделать на ThreadPool.

Займусь.


Готово
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 07.05.2011
Ответить


aspirant Перейти
Это такой протокол. См. стр. 7 P2ClientFate.doc:


Прочитал. Не понял насчет интенсивности вызова этого метода. Я могу какое-то сообщение пропустить, если не успею вызвать метод ProcessMessage? Или они где-то копяться? С чем тогда прикол этого метода? Почему нельзя просто подписаться на событие и получать данные через него?

Меня еще смутил параметр PollInterval, который передавался в ProcessMessage. Прочитал доку, оказалось что это не PollInterval, а PollTimeout. Стало понятнее. Я так понял, это то время, на которое будет заблокирован метод ProcessMessage, если не будет нового сообщения?

Видел интерфейс IP2MessageReceiver? Я вот думаю, а это случайно не альтернатива ProcessMessage, только без вечного цикла?

aspirant Перейти
PlazaSchemaParser не используется вообще. Я его оставил, потому что уже сделал и жалко было выкидывать готовый, хотя и сырой, парсер ini-файлов потоков репликации. Может быть оставим PlazaTableSerializer и выкинем PlazaSchemaParser?


Как тебе будет виднее. Но R# говорит, что PlazaSchemaParser все же используется. И, судя по коду, PlazaTableSerializer пишет ini схемы, а PlazaSchemaParser читает. А нам вроде бы и то и другое нужно для работы.

aspirant Перейти
Наверное, да. Но можем усложнить жизнь. Синтаксис в ini-файлов потоков репликации немного отличается (чуть сложнее). Может быть оставим, как есть?


Давай оставим.
Автор топика
Спасибо:

aspirant

Фотография
Дата: 07.05.2011
Ответить


Mikhail Sukhov Перейти

Прочитал. Не понял насчет интенсивности вызова этого метода. Я могу какое-то сообщение пропустить, если не успею вызвать метод ProcessMessage? Или они где-то копяться? С чем тогда прикол этого метода? Почему нельзя просто подписаться на событие и получать данные через него?


Алгоритм подписки на потоки брал из примера плазовцев. Там этот метод вызывается в отдельном thread'е в непрерывном цикле. Во вторник попробую закомментить вызов этого метода и посмотреть, идут ли данные из потоков. Почему они так сделали, мне тоже непонятно.


Mikhail Sukhov Перейти
Меня еще смутил параметр PollInterval, который передавался в ProcessMessage. Прочитал доку, оказалось что это не PollInterval, а PollTimeout.

PollInterval сейчас исправлю на PollTimeout. Я почему-то поменял название этого параметраConfused

Mikhail Sukhov Перейти
Я так понял, это то время, на которое будет заблокирован метод ProcessMessage, если не будет нового сообщения?


Да, это так.

Mikhail Sukhov Перейти
Видел интерфейс IP2MessageReceiver? Я вот думаю, а это случайно не альтернатива ProcessMessage, только без вечного цикла?


В доке как-то все размыто написано. У меня создалось впечатление, что этот интерфейс не относится к данным из потоков. Он нужен для отправки заявок и т.д., а я в это не влезал вообще.


Mikhail Sukhov Перейти
aspirant Перейти
PlazaSchemaParser не используется вообще. Я его оставил, потому что уже сделал и жалко было выкидывать готовый, хотя и сырой, парсер ini-файлов потоков репликации. Может быть оставим PlazaTableSerializer и выкинем PlazaSchemaParser?


Как тебе будет виднее. Но R# говорит, что PlazaSchemaParser все же используется. И, судя по коду, PlazaTableSerializer пишет ini схемы, а PlazaSchemaParser читает. А нам вроде бы и то и другое нужно для работы.


Да, забыл. PlazaSchemaParser используется для десериализации данных из ini-файлов. Но эта фича нам пока не нужна, поэтому предлагаю вместо вызовов PlazaSchemaParser пока выкидывать NotImplementedException()?
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 07.05.2011
Ответить


aspirant Перейти
aspirant Перейти
Mikhail Sukhov Перейти
PlazaStreamManager сейчас создает отдельные потоки для каждного стрима. Расточительно по ресурсам. Лучшем переделать на ThreadPool.

Займусь.


Готово


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

Идея работы пула в рамках PlazaStreamManager мне видется в заведении таймера (который Threading.Timer, потому что он основан на пуле потоков), в обработчике которого будут перебираться все соединения, и для них будет вызываться ProcessMessage. Тоесть, как только один "зависнет" в ожидании сообщения, таймер создаст еще один пуловый поток, который будет обрабатывать следующее свободное соединение (иначе все потоки будут ждать одно и то же соединение).
Автор топика
Спасибо:

aspirant

Фотография
Дата: 08.05.2011
Ответить


Mikhail Sukhov Перейти
Смотрел. Небольшой ликбез по работе пула потоков. В пул потоков мы помещаем небольшие действия, которых может быть очень много, но при этом отрабатывают они быстро. У тебя же помещается вечный цикл, что не является быстрой отработкой.


Насчет Threadpool'а знаю. Именно из-за этого изначально создавал полноценные Thread'ы.

Mikhail Sukhov Перейти
Идея работы пула в рамках PlazaStreamManager мне видется в заведении таймера (который Threading.Timer, потому что он основан на пуле потоков), в обработчике которого будут перебираться все соединения, и для них будет вызываться ProcessMessage. Тоесть, как только один "зависнет" в ожидании сообщения, таймер создаст еще один пуловый поток, который будет обрабатывать следующее свободное соединение (иначе все потоки будут ждать одно и то же соединение).


У меня здесь вот какое предложение. Сейчас мы для каждого стрима создаем отдельный Connection. А что если мы пойдем по более простому пути, как в примере у плазовцев: все стримы используют один Connection. В этом случае создается только один Thread, внутри которого в бесконечном цикле вызвается ProcessMessage. Если будут тормоза, тогда уже будем делать, как ты предлагаешь. Напиши, что думаешь.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 08.05.2011
Ответить


aspirant Перейти
У меня здесь вот какое предложение. Сейчас мы для каждого стрима создаем отдельный Connection. А что если мы пойдем по более простому пути, как в примере у плазовцев: все стримы используют один Connection. В этом случае создается только один Thread, внутри которого в бесконечном цикле вызвается ProcessMessage. Если будут тормоза, тогда уже будем делать, как ты предлагаешь. Напиши, что думаешь.


С этого и нужно было начать.Smile
Автор топика
Спасибо:

aspirant

Фотография
Дата: 09.05.2011
Ответить


Mikhail Sukhov Перейти
С этого и нужно было начать.Smile


Залил, на неделе нужно тестировать.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 09.05.2011
Ответить


aspirant Перейти
Mikhail Sukhov Перейти
С этого и нужно было начать.Smile


Залил, на неделе нужно тестировать.


Исправил код. У тебя там хитрая логика с остановкой и перезапуском потока была, которая по сути не нужно вообще. Ну что это за робот, которому потоки не нужно?Smile Поток пуская живет все время и закрывается при закрытие PlazaTrader. Меньше сложностей, меньша багов.
Автор топика
Спасибо:

aspirant

Фотография
Дата: 09.05.2011
Ответить


Mikhail Sukhov Перейти
Ну что это за робот, которому потоки не нужно?Smile


Вообще да. Как минимум, системные всегда будут.
Спасибо:

aspirant

Фотография
Дата: 10.05.2011
Ответить


aspirant Перейти

Да, забыл. PlazaSchemaParser используется для десериализации данных из ini-файлов. Но эта фича нам пока не нужна, поэтому предлагаю вместо вызовов PlazaSchemaParser пока выкидывать NotImplementedException()?


Залил
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 10.05.2011
Ответить


aspirant Перейти
aspirant Перейти

Да, забыл. PlazaSchemaParser используется для десериализации данных из ini-файлов. Но эта фича нам пока не нужна, поэтому предлагаю вместо вызовов PlazaSchemaParser пока выкидывать NotImplementedException()?


Залил


Можешь первый таск добить?
Автор топика
Спасибо:

aspirant

Фотография
Дата: 10.05.2011
Ответить


aspirant Перейти
Mikhail Sukhov Перейти
С этого и нужно было начать.Smile


Залил, на неделе нужно тестировать.


Тестировал, потоки идут, стаканы есть. Без ProcessMessage, кстати, не работает.
Спасибо:

aspirant

Фотография
Дата: 10.05.2011
Ответить


Mikhail Sukhov Перейти
aspirant Перейти
aspirant Перейти

Да, забыл. PlazaSchemaParser используется для десериализации данных из ini-файлов. Но эта фича нам пока не нужна, поэтому предлагаю вместо вызовов PlazaSchemaParser пока выкидывать NotImplementedException()?


Залил


Можешь первый таск добить?


Постараюсь завтра-послезавтра
Спасибо:

Bell

Фотография
Дата: 10.05.2011
Ответить


как же вы 4 месяца занимались Плазой и только теперь выясняете, что такое ProcessMessage?
судя по техническому форуму РТС, без ясного понимания, как это работает, легко получить тормозящий код.
проконсультируйтесь с Кукушкиным, который вроде хорошо разобрался. Или с ртс-овцами. Дока там ужасная.
Спасибо:

aspirant

Фотография
Дата: 11.05.2011
Ответить


Mikhail Sukhov Перейти
И да, кто может мне объяснить в чем смысл всех этих ProcessMessage?


Вот, кстати, интересная ветка.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 11.05.2011
Ответить


aspirant Перейти
Mikhail Sukhov Перейти
И да, кто может мне объяснить в чем смысл всех этих ProcessMessage?


Вот, кстати, интересная ветка.


Или я не понимаю схему работы сообщений от Плазы, или там обсуждается какая-то ерунда. Таймаут надо ставить по максимуму, так как он дает возможность не вызывать в холостую метод ProcessMessage. Ставить 1 милилсекунду нет никакого смысла, так как данные от Плазы накапливаются (это я так думаю), и все равно ничего не пропустится.
Автор топика
Спасибо:

aspirant

Фотография
Дата: 11.05.2011
Ответить


Mikhail Sukhov Перейти
Или я не понимаю схему работы сообщений от Плазы, или там обсуждается какая-то ерунда. Таймаут надо ставить по максимуму, так как он дает возможность не вызывать в холостую метод ProcessMessage. Ставить 1 милилсекунду нет никакого смысла, так как данные от Плазы накапливаются (это я так думаю), и все равно ничего не пропустится.

Вот механизм работы:
Цитата:
Таймаут - это сколько висеть на сокете в ожидании пакета данных, если пакет уже есть, то метод вернется сразу как только обработаются все события получения данных.

Остальное, да, вода. Поток используется только под этот метод, поэтому ставить маленькие периоды смысла нет.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 11.05.2011
Ответить


aspirant Перейти
Mikhail Sukhov Перейти
Или я не понимаю схему работы сообщений от Плазы, или там обсуждается какая-то ерунда. Таймаут надо ставить по максимуму, так как он дает возможность не вызывать в холостую метод ProcessMessage. Ставить 1 милилсекунду нет никакого смысла, так как данные от Плазы накапливаются (это я так думаю), и все равно ничего не пропустится.

Вот механизм работы:
Цитата:
Таймаут - это сколько висеть на сокете в ожидании пакета данных, если пакет уже есть, то метод вернется сразу как только обработаются все события получения данных.

Остальное, да, вода. Поток используется только под этот метод, поэтому ставить маленькие периоды смысла нет.


Вот и возник вопрос. Есть сообщения копяться от Плазы, зачем тогда вообще вызывать ProcessMessage? Почему не сделали просто вызов события?
Автор топика
Спасибо:

aspirant

Фотография
Дата: 11.05.2011
Ответить


Mikhail Sukhov Перейти
Вот и возник вопрос. Есть сообщения копяться от Плазы, зачем тогда вообще вызывать ProcessMessage? Почему не сделали просто вызов события?


Не знаю, но без вызова точно не работает. Только что еще раз проверил.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 11.05.2011
Ответить


aspirant Перейти
Mikhail Sukhov Перейти
Вот и возник вопрос. Есть сообщения копяться от Плазы, зачем тогда вообще вызывать ProcessMessage? Почему не сделали просто вызов события?


Не знаю, но без вызова точно не работает. Только что еще раз проверил.


=) Я верю что не работает. С первого раза поверил. Но думаю тут не спроста. Или косяк в архитектуре Плазы (не удивлюсь) или мы что-то упустили.
Автор топика
Спасибо:

aspirant

Фотография
Дата: 11.05.2011
Ответить


Mikhail Sukhov Перейти
=) Я верю что не работает. С первого раза поверил.

Это я сам себя проверял. Порой кажется, что все сделал правильно, а упустишь какую-то мелочь и приходится есть свой галстук. Образно, конечноSmile

Mikhail Sukhov Перейти
Но думаю тут не спроста. Или косяк в архитектуре Плазы (не удивлюсь) или мы что-то упустили.


Мне все-таки кажется, что первое. Повторюсь: алгоритм взят из их примера BaselessClient.
Спасибо:

Bell

Фотография
Дата: 11.05.2011
Ответить


ProcessMessage это прокачка очереди сообщений на сокете "вручную". Почему сделано так, а не иначе хз. Для совместимости чего-то с чем-то. Без понимания всех нюансов (а их там много) может быть плохо, потому что внутри есть критические секции, при работе с одним объектом из разных тредов может происходить маршаллинг. Общее правило кажется(!) один поток - один объект коннекшн.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 11.05.2011
Ответить


Bell Перейти
ProcessMessage это прокачка очереди сообщений на сокете "вручную". Почему сделано так, а не иначе хз. Для совместимости чего-то с чем-то. Без понимания всех нюансов (а их там много) может быть плохо, потому что внутри есть критические секции, при работе с одним объектом из разных тредов может происходить маршаллинг. Общее правило кажется(!) один поток - один объект коннекшн.


Это как бы правило МТА. Только все равно не понятно насчет ProcessMessage.
Автор топика
Спасибо:

Bell

Фотография
Дата: 11.05.2011
Ответить


Mikhail Sukhov Перейти
Только все равно не понятно насчет ProcessMessage.

Почему так сделано? Это надо спрашивать у разработчиков. Они это где-то объясняли, но я не понял. У меня на Плазу вообще идиосинкразия. Вот всё надеялся, что вы сделаете нормально...
Спасибо:
1 2  >

Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy