Вопросы \ предложения по коннектору

По 1) вопросу - предложение сделать класс PlazaStreamRegistry не статичным, соответственно и поля тоже.
С такими изменениями мне удалось получить данные по 2м подключениям-логинам.


Возник новый вопрос\баг:
4) При вызове Disconnect загрузка ЦП повышается до 100% - висит постоянно в PlazaStreamManager, на

1. Да, все правильно. Видимо нужно его сделать или по аналогии с колонками, или сделать instance.
2. PlazaTrader.StartStream
3. Никак. PlazaConnectionPool создаем подключения для транзакций и для потока данных. Вроде еще есть одно.

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



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



PlazaConnectionPool создает два подключения: одно для экспорта данных из таблиц (SS_0), одно для отправки транзакций (SS_1). Менять количество подключений пока не возможно.

Я немножко подправил это место. Ты замерял, сколько примерно код висит при отключении? У меня на тестовом полигоне отключение в среднем происходит за 5-30 секунд. Если это долго, нужно будет что-то думать.

1) Не поможет. У нас далее static есть у PlazaTableRegistry, PlazaColumnRegistry... Вообще возникает сильная перегрузка с классами - PlazaTableRegistry, PlazaColumnRegistry выглядят лишними. Для чего они?
2) У нас сейчас по дефолту запускаются сразу все потоки - а не все они всегда нужны.
4) Код висит много, больше минуты. Но вспомнил - происходит это при 2х подключениях. Учитывая что они работают сейчас неправильно - можно пока не думать. Надо править пункт 1). :)

PlazaTableRegistry, PlazaColumnRegistry - это метаданные, поэтому они могут остаться static. PlazaStreamRegistry нужно рефакторить, чтобы была возможность одновременного подключения нескольких логинов.



Из 44 потоков сейчас по дефолту запускается только 13. Можно, наверное, дать юзеру возможность указывать, какие потоки запускать по дефолту, но тогда не все объекты фреймворка будут мапиться. Это приемлемо?
Набор потоков по умолчанию создавал Михаил, может быть он тоже что-нибудь прокомментируют.

По поводу PlazaTableRegistry,PlazaColumnRegistry,PlazaStreamRegistry - надо рефакторить всё, на мой взгляд, есть некий излишек.
По поводу потоков теперь понятно, согласен.

Вчера эти вопросы с Мишей как раз обсуждали, будут идеи как сделать лучше - залью, тут отпишусь.


Кстати, после Мишиного фикса ночного загрузка ЦП теперь и после коннекта 70-90% всегда . После дисконнекта - столько же. стабильность - это уже хорошо :)))
Наблюдается и с 1 подключением, и с 2мя.

Не помогло совсем.

Я положил изменения, модифицировал немного методы старта \ остановки экспорта.

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

1) Зачем создания PlazaStream в конструкторе PlazaStreamRegistry? А если нам не все из этих PlazaStream понадобятся?
2) Для чего нужен как PlazaStreamRegistry, так и PlazaStreamManager. По сути PlazaStreamRegistry - enum, в котором собраны потоки. Если их создавать не сразу, а по мере необходимо - данный класс будет вообще не нужен.
3) PlazaTableRegistry - зачем? Внешне похож на PlazaStreamRegistry.
4) PlazaColums - зачем тут Table?
5) PlazaColumnRegistry - аналогично, зачем данный класс? Тут аналогично пунктам 1-2.
6) PlazaColumns, PlazaColumnList - какой смысл в создании и того, и того?


P.S. Миша вчера в разговоре высказал предположение что мы перемудрили, т.к. когда возникают баги, как со статическим конструктором PlazaColumnRegistry - это не спроста. Надо что-то менять. :)

PlazaStreamManager управляет запущенным PlazaStream'ами. Наверное, его код можно перенести в PlazaTrader, но мне кажется, это слишком много для PlazaTrader.

PlazaColumns - это базовый класс для всех метаданных - таблиц потоков репликации. Table - это неубранный остаток предыдущей реализации.

PlazaColumnList, наскольку я понимаю, потому что писал Миша, - это такой custom вариант SynchronizedCollection<PlazaColumn>, который имеет представление о бизнес-логике работы с колонками таблиц потоков репликации.

PlazaStreamRegistry/PlazaTableRegistry/PlazaColumnRegistry - их лучше прокомментировать Мише.

2Alexander: может быть ты предложишь что-то другое по организации метаданных, посмотрев свежим глазом? Стоит честно признать, что бета получилась очень сырая. Наверное, сработало желание поскорее хоть что-то зарелизить[huh]