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



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


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

Теги:


Спасибо:




1 2 3  > >>
aspirant

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


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

Займусь.

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

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

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


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

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

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

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


Mikhail Sukhov GoTo
Кто что сделает?

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

aspirant

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


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

Займусь.


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

Mikhail Sukhov

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


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


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

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

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

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


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

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


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

aspirant

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


Mikhail Sukhov GoTo

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


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


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

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

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


Да, это так.

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


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


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


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


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

Mikhail Sukhov

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


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

Займусь.


Готово


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

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

aspirant

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


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


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

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


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

Mikhail Sukhov

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


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


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

aspirant

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


Mikhail Sukhov GoTo
С этого и нужно было начать.Smile


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

Mikhail Sukhov

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


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


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


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

aspirant

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


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


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

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

loading
clippy