Зависает при одновременном подключении двух инстансов

[serebrennikovvitaly]

Собственно, проблема такая: запускаем 1 инстанс, (например Quik sharp Demo, жмем кнопку Connect), все ок.

Далее, запускам второй инстанс этого же приложения, также жмем Connect. И все, завис намертво.

Дебаг показывает, что виснет тут:

Если еще ниже пройти, то виснет вот в этом месте:

Можно ли поправить? Чтоб хотя бы на этапе создания экземпляра Quik возвращал null. Или как еще можно проверить, что порт занят другим подключением?

[Pr0phet1c]

1. С какой целью Вы запускаете второй экземпляр приложения с коннектом на тот же порт? Очевидно же, что это и не должно работать.
2. Предложите свое решение (в виде PR).

[nick-ez]

Если Вам надо запустить более одного робота то на канале у Привала (#221) есть видео как это сделать с помощью activator.createinstance. я именно так делал

[serebrennikovvitaly]

1. С какой целью Вы запускаете второй экземпляр приложения с коннектом на тот же порт? Очевидно же, что это и не должно работать.

Проблема в том, что иногда при установки соединения сам quik зависает и ничего не отдает, соответственно при перезапуске службы как-бы другой инстанс подключается к квику по этому же порту. Помогает только перезапуск квика полностью.
Как решение (в теории) помог бы таймаут, добавленный в getWorkingFolder, и вообще во все обращения к квику

[serebrennikovvitaly]

Сделал на тесте так, предлагаю добавить в библиотеку:

[dnmsk]

Эта проблема больше на стороне использования tpl. Если нет инстанса на порту для получения рабочей директории квика алгоритм уходит в лок.
Рабочая директория нужна для MemoryMappedFile и генерации номера транзакции.
Cделал решение - перейти на номер транзакции из Environment.TickCount64, тем более что MMF нет на линуксе.
Если такое решение в парадигме проекта - мог сделать PR

[Pr0phet1c]

@dnmsk, К сожалению, я не могу назвать Ваше решение приемлемым.
Суть вот в чем: С учетом ряда особенностей работы биржи по хранению данных о сделках и транзакциях, нам необходимо обеспечить уникальность номеров транзакций как минимум в течение двух суток. На самом деле, в ряде случаев, требуется больше, но это тот минимум на который можно пойти с минимальным риском.
Предложенное Вами решение, по очевидным причинам НЕ обеспечивает такой уникальности, не только в течении двух суток, но даже в течение одного дня (если по каким-либо причинам система будет перезагружена).

[dnmsk]

@Pr0phet1c Конечно, любое не привязанное к 1 знаменателю значение слабо подходит, время или тики со старта системы могут дублироваться.
Другое дело что текущая реализация содержит 2 потенциальные трудности.
Могу еще предложить самописный аналог mmf, лежащий в директории с программой (расположение квика и QUIKSharp также может быть на разных серверах). Либо подобие DI: с инжектом зависимости в конструктор генерирующей номер транзакции (для windows как есть, для линукс в директории исполнения программы) и возможностью написания своего варианта. Или ничего не делать :-)

[Pr0phet1c]

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

[serebrennikovvitaly]

Эта проблема больше на стороне использования tpl. Если нет инстанса на порту для получения рабочей директории квика алгоритм уходит в лок. Рабочая директория нужна для MemoryMappedFile и генерации номера транзакции.

Ну так может проще рабочую директорию квика просто передать через входящий параметр конструктора? Ну и таймаут все же добавить

[Pr0phet1c]

Ну так может проще рабочую директорию квика просто передать через входящий параметр конструктора? Ну и таймаут все же добавить

1. На счет директории надо подумать, когда будет время.
2. Решение с таймаутом, о котором Вы писали нерабочее. Почитайте справку Квика по функции getWorkongFolder. Она не принимает никаких параметров.

А пока рекомендую не создавать экземпляр объекта в заведомо нерабочей конфигурации системы.