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

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:

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

Готово

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

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

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

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

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

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

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

Давай оставим.

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()?

aspirant:

aspirant:

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

Готово

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

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

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

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

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

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

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

С этого и нужно было начать.[smile]

Mikhail Sukhov: С этого и нужно было начать.[smile]

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

aspirant:

Mikhail Sukhov: С этого и нужно было начать.[smile]

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

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

Mikhail Sukhov: Ну что это за робот, которому потоки не нужно?[smile]

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