Корректное завершение работы

[Mikhail Sukhov]

Когда нужно делать выгрузку библиотеки? Дело в том, что в колбэке этого делать нельзя, так как библиотека еще используется. И сразу после отправки команды Disconnect так же делать нельзя, так как не известно когда придет ответ.

[klimov]

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

[Mikhail Sukhov]

Следующей строчкой после SendCommand вы имеет следующую ситуацию. 2 потока. Основной поток стоит на позиции после SendMessage. Второй поток стоит в Callback от этой самой команды. UnInitialize проходит без ошибки. На FreeLibrary  появляется AccessViolation.

[klimov]

Да, согласен.

Можно после выполнения команды Disconnect сделать небольшой sleep (заведомо больше по времени, чем обработка <server_status> connected=false  в коллбэк-функции)

[Mikhail Sukhov]

Можно после выполнения команды Disconnect сделать небольшой sleep (заведомо больше по времени, чем обработка <server_status> connected=false  в коллбэк-функции)

Не помогает (10 сек ждал, колбэк гарантированно отработал судя по логу). Что логично, так как в процессе остались 2 потока, которые создаются при коннекте.

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

Может быть дать возможность как-то выключать все эти чудесные механизмы? Через настройки там какие-нибудь?

[klimov]

Какую версию коннектора вы используете?

Пришлите на support@transaq.ru все логи Коннектора, чтобы мы могли посмотреть на глюки механизма переподключений

В момент AccessViolation при вызове FreeLibrary, возможно создался отладочный файл (он имеет расширение mdmp) Если  он есть, то прошу его также прислать.

[Mikhail Sukhov]

Файла такого нет. Последние строчки лога XDF

131225-151232.287 5752   [2728]   Inf << <server_status id="2" connected="true"/>
131225-151329.288 5752   [3384]   Inf >> <command id="disconnect" />
131225-151329.816 5752   [2728]   Inf << <server_status id="2" connected="false"/>
131225-151329.817 5752   [3384]   Inf << <result success="true"/>
131225-151345.237 5752   [3384]   Sys >< UnInitialize requested...

Версия файла 5.8.2.4

Логи переподключения нужно ждать, когда интернет будет нестабильным. Просьба сделать параметры, которыми можно было бы выключить все эти самодостаточноые механизмы.

[Mikhail Sukhov]

И все же. Возможно ли хоть как-то выключать коннектор или коннектор невозможно выключить?

[Сорвачев Сергей]

Следующей строчкой после SendCommand вы имеет следующую ситуацию. 2 потока. Основной поток стоит на позиции после SendMessage. Второй поток стоит в Callback от этой самой команды. UnInitialize проходит без ошибки. На FreeLibrary  появляется AccessViolation.

Добрый день, Михаил.
А можно поподробнее о Вашем проекте:
реализация у Вас на с++?
2 потока, о которых Вы пишете, это реализация Вашего проекта?
Можете привести примерный сценарий взаимодействия с библиотекой коннектора (с перечислением управляющих функций, т.е. Initialize, SendCommand(connect/disconnect), Load/FreeLibrary).

Необходимость остановки коннектора на уровне выгрузки библиотеки в процессе работы программы чем вызвана? Или указанная проблема возникает в момент завершения  Вашей программы?
Если есть возможность, можете написать небольшой тест библиотеки, который воспроизводит проблему у Вас и прислать его на support@transaq.ru?

[Mikhail Sukhov]

2 потока, о которых Вы пишете, это реализация Вашего проекта?

Один поток - это основной поток. Если говорить про Windows, то каждое приложение имеет минимум один поток. Второй поток - это поток колбэка. Я его не создавал. Видимо создался сам ТКоннектором. Если вы умеете пользоваться Vusual Studio, то там можно посмотреть в окно Threads.

Необходимость остановки коннектора на уровне выгрузки библиотеки в процессе работы программы чем вызвана?

Вроде как это сценарий корректного завершения работы с ТКоннектором. Описан в документации. Если сценарий неправильный, то просьба хотя бы сюда написать, какой правильный.

Если есть возможность, можете написать небольшой тест библиотеки, который воспроизводит проблему у Вас и прислать его на support@transaq.ru?

Ребят, давайте что-ли на реалии смотреть чуть трезвее. Я вам написал баг репорт. Баг репорт подтвержден Климовым. Механизмы авто переподключения о которых я писал, так же описаны в вашей документации (хотя там написано про Финам, не знаю кто ее писал, думаю сами между собой разберетесь). Писать примеры я не буду, так как лично для себя не вижу смысла, да и в лом =) Хотите - правьте багу. Хотите - нет. Я для очистки совести вам написал об их сущенствовании. Считаю свою часть работы выполненной на 100% =)

[klimov]

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

В любом случае, мы еще раз проверим корректность работы библиотеки при UnInitialize и последующем FreeLibrary. О результатах сообщим

[Mikhail Sukhov]

В любом случае, мы еще раз проверим корректность работы библиотеки при UnInitialize и последующем FreeLibrary. О результатах сообщим

Что-то мы ходим вокруг да около. Я вам описал причину крэша еще 23 декабря в этом топике. 24 декабря вы поняли, о чем я пишу. А теперь все с начала, новый год? =)

Нельзя выгружать библиотеку если в ней есть работающий код. Это и приводит к крэшу. Проблема в том, что ТКоннектор невозможно остановить. Там живут свои потоки, свой контроль за подключением. Я задал вопрос 25 декабря, как все это выключить. Как сделать так, чтобы ТКоннектор ничего параллельно не делал в фоне. Ответив на этот вопрос вы ответите и на причину того, почему ТКоннектор невозможно выключить.

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

Посмотрите на то, как сделали в Plaza 2. Никаких скрытых потоков. Пользовательский код сам создает сколько нужно потоков и сам выбирает данные из очереди. Тогда проблема race condition уйдет сама.

Фразы вида "много внешних разработчиков" - это ни о чем. Я вам пишу про явные проблемы. Достаточно взглянуть на документацию, подумать как это работает, и все очевидно станет. Какие заплатки делают другие разработчики я не знаю. Но я вам предлагаю убрать подход с заплатками и сделать коннектор нормальным. Чтобы его логика работы было детерминированной. Я вам ранее уже писал о проблеме http://www.transaq.ru/forum/index.php?topic=1258.0 после чего вы изменили ТКоннектор (неправильно, конечно, сделали, но хоть так, иначе с ММВБ было вообще не возможно работать). Предлагаю и в этот раз сделать фикс. Только вначале скажите, как вы хотите его сделать. Чтобы не было как с кодами площадок.

[klimov]

Михаил, спасибо за настойчивость

Доработали UnInitialize , теперь dll должна выгружаться нормально

Кстати, чтобы отключить авто-переподключение можно в команде "connect" задавать значение session_timeout меньше, чем значение request_timeout

[Mikhail Sukhov]

Хочу ответить, что до сих пор не работает. После того как вы отписали, еще 2 раза мне через личку давали 2 неработающие версии.

[Sid]

Михаил, чем закончилась эта история ?
Получается что при работе с транзак-коннектором совместно с S#-библиотекой могут быть проблемы.