Fix memory leak. Dispose in recreating instances.

[chislovMax]

Решение этого ишью

• Везде где сделал Dispose где объекты IDisposable в классе QuikService. так как даже при нормальной работе потребляемая память медленно, но верно, увеличивалась

Самый важный исправленный момент, который побудил исправления, это лик во время отключения соединения квика к серверу, когда был уже подключен Quki# к нему. И если после этого попробовать запустить Quki# снова - уходил в бесконечный цикл внутри таски _callbackInvokerTask:

• _cts никто не отменял (он как раз пересоздался при StartService)
• Вызывается метод _receivedCallbacksChannel.Reader.ReadAsync (типа SingleConsumerUnboundedChannel ) передавая _cts.Token
• внутри библиотека System.Threading.Channel создает инстанс AsyncOperation
• В свою очередь AsyncOperation делает к этому токену регистрацию коллбека на отмену, который сохраняется в цепочке колбэков этого _cts.
• После пересоздания этой операции SingleConsumerUnboundedChannel делает отмену предыдущей операции, при этом уже не передавая токен (наш токен, напомню, никто не отменял).
• По дефолту используется CanseletionToken.None и выбрасывается исключение OperationCanceledException отлавливаемое уже нашей таской _callbackInvokerTask, и снова пойдёт на следующую итерацию, результат которой будет тот же.
• По итогу каждой итерации в _cts будет 1 регистрация колбэка (CallbackNode), в которой будет ссылка на прошлую отменённую AsyncOperation, там же отмена сохраняет само исключение, что демонстрирует один из скринов в ишью.
• Рост потребляемой памяти в цикле ~ 1Гб/мин

Результат PR: Создан зависимый CancellationTokenSource, если отменится _cts, то и отменит этот же, операция завершится, этот зависимый токен уничтожается сразу после обработки асинхронной операции чтения, если возникает такой цикл CallbackNode и всё, что к нему было приложено так же зачищается.

Все остальные правки с вызовами Dispose были намерено сделаны не в момент отмены, а в основном при пересозданиях (ничего не ломает, но работает лучше)

[Pr0phet1c]

Изменения действительно важные и нужные. Спасибо. Хотя, описанного потребления памяти никогда не наблюдал у себя (обычно работает одновременно 3-4 программных комплекса, подключенных к двум терминалам от разных брокеров), и редко когда потребление памяти одним приложением превышает 100Мб. Код просмотрел бегло, и вроде бы ничего критичного не увидел. Так что надеюсь, Вы протестировали изменения в реальной работе. Сейчас перенесу изменения к себе и сам понаблюдаю что изменилось по сравнению с текущим положением дел.

[buybackoff]

@chislovMax Спасибо! Тому коду 6-7 лет, когда я бегло посмотрел на использование CTS после issue, подумал - кто же так замудренно написал!? 😄

Я добавил System.Threading.Channel не так давно, почти не думая, чтобы решить проблему reordering-а сообщений. Я так понимаю, утечка в первую очередь из-за каналов? До этого Таски просто отправлялись в пул потоков.

[chislovMax]

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