Transaq
СБО "Transaq" => TRANSAQ Connector => Topic started by: Mikhail Sukhov on Декабря 23, 2013, 12:03:00 am
-
Когда нужно делать выгрузку библиотеки? Дело в том, что в колбэке этого делать нельзя, так как библиотека еще используется. И сразу после отправки команды Disconnect так же делать нельзя, так как не известно когда придет ответ.
-
Команда disconnect является синхронной, т.е. при ее выполнении SendCommand вернет результат только после того, как коннектор отключится от сервера.
Так что можно после выхода из SendCommand позвать UnInitialize, а потом выгрузить библиотеку.
-
Следующей строчкой после SendCommand вы имеет следующую ситуацию. 2 потока. Основной поток стоит на позиции после SendMessage. Второй поток стоит в Callback от этой самой команды. UnInitialize проходит без ошибки. На FreeLibrary появляется AccessViolation.
-
Да, согласен.
Можно после выполнения команды Disconnect сделать небольшой sleep (заведомо больше по времени, чем обработка <server_status> connected=false в коллбэк-функции)
-
Можно после выполнения команды Disconnect сделать небольшой sleep (заведомо больше по времени, чем обработка <server_status> connected=false в коллбэк-функции)
Не помогает (10 сек ждал, колбэк гарантированно отработал судя по логу). Что логично, так как в процессе остались 2 потока, которые создаются при коннекте.
Я уже писал вам через Финам, что нужно убрать все эти потоки, и дать возможность пользовательскому коду организовывать взаимодействие. Заодно напишу, еще и то, чтобы как-то выключать механизм переподключений, который судя по всему живет свой жизнью. При слабом интернете этот механизм начинает глючить. При этом ручное подключение работает лучше, так как пользователь сам может определить, через сколько примерно времени инет снова отвалиться (кто пользуется плохим интернетом тот знает, что там бывает как-бы периоды стабильного подключения, так и отвала).
Может быть дать возможность как-то выключать все эти чудесные механизмы? Через настройки там какие-нибудь?
-
Какую версию коннектора вы используете?
Пришлите на support@transaq.ru все логи Коннектора, чтобы мы могли посмотреть на глюки механизма переподключений
В момент AccessViolation при вызове FreeLibrary, возможно создался отладочный файл (он имеет расширение mdmp) Если он есть, то прошу его также прислать.
-
Файла такого нет. Последние строчки лога 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
Логи переподключения нужно ждать, когда интернет будет нестабильным. Просьба сделать параметры, которыми можно было бы выключить все эти самодостаточноые механизмы.
-
И все же. Возможно ли хоть как-то выключать коннектор или коннектор невозможно выключить?
-
Следующей строчкой после SendCommand вы имеет следующую ситуацию. 2 потока. Основной поток стоит на позиции после SendMessage. Второй поток стоит в Callback от этой самой команды. UnInitialize проходит без ошибки. На FreeLibrary появляется AccessViolation.
Добрый день, Михаил.
А можно поподробнее о Вашем проекте:
реализация у Вас на с++?
2 потока, о которых Вы пишете, это реализация Вашего проекта?
Можете привести примерный сценарий взаимодействия с библиотекой коннектора (с перечислением управляющих функций, т.е. Initialize, SendCommand(connect/disconnect), Load/FreeLibrary).
Необходимость остановки коннектора на уровне выгрузки библиотеки в процессе работы программы чем вызвана? Или указанная проблема возникает в момент завершения Вашей программы?
Если есть возможность, можете написать небольшой тест библиотеки, который воспроизводит проблему у Вас и прислать его на support@transaq.ru?
-
2 потока, о которых Вы пишете, это реализация Вашего проекта?
Один поток - это основной поток. Если говорить про Windows, то каждое приложение имеет минимум один поток. Второй поток - это поток колбэка. Я его не создавал. Видимо создался сам ТКоннектором. Если вы умеете пользоваться Vusual Studio, то там можно посмотреть в окно Threads.
Необходимость остановки коннектора на уровне выгрузки библиотеки в процессе работы программы чем вызвана?
Вроде как это сценарий корректного завершения работы с ТКоннектором. Описан в документации. Если сценарий неправильный, то просьба хотя бы сюда написать, какой правильный.
Если есть возможность, можете написать небольшой тест библиотеки, который воспроизводит проблему у Вас и прислать его на support@transaq.ru?
Ребят, давайте что-ли на реалии смотреть чуть трезвее. Я вам написал баг репорт. Баг репорт подтвержден Климовым. Механизмы авто переподключения о которых я писал, так же описаны в вашей документации (хотя там написано про Финам, не знаю кто ее писал, думаю сами между собой разберетесь). Писать примеры я не буду, так как лично для себя не вижу смысла, да и в лом =) Хотите - правьте багу. Хотите - нет. Я для очистки совести вам написал об их сущенствовании. Считаю свою часть работы выполненной на 100% =)
-
Михаил,
на данный момент достаточно много внешних разработчиков используют Коннектор, но о подобных проблемах сообщений нам не поступало. Возможно, есть какой-то нюанс в том, как именно в вашей программе организовано взаимодействие с библиотекой. Именно поэтому Сергей задает эти вопросы.
В любом случае, мы еще раз проверим корректность работы библиотеки при UnInitialize и последующем FreeLibrary. О результатах сообщим
-
В любом случае, мы еще раз проверим корректность работы библиотеки при UnInitialize и последующем FreeLibrary. О результатах сообщим
Что-то мы ходим вокруг да около. Я вам описал причину крэша еще 23 декабря в этом топике. 24 декабря вы поняли, о чем я пишу. А теперь все с начала, новый год? =)
Нельзя выгружать библиотеку если в ней есть работающий код. Это и приводит к крэшу. Проблема в том, что ТКоннектор невозможно остановить. Там живут свои потоки, свой контроль за подключением. Я задал вопрос 25 декабря, как все это выключить. Как сделать так, чтобы ТКоннектор ничего параллельно не делал в фоне. Ответив на этот вопрос вы ответите и на причину того, почему ТКоннектор невозможно выключить.
Я даже больше того скажу. Из-за того, что SendCommand является блокирующим методом, сейчас в легкую из-за этой параллельности может возникнуть ситуация, когда сначала придет оповещение о заявки через поток данных, а затем вернется результат из SendCommand. И информация о заявке будет потеряна.
Посмотрите на то, как сделали в Plaza 2. Никаких скрытых потоков. Пользовательский код сам создает сколько нужно потоков и сам выбирает данные из очереди. Тогда проблема race condition уйдет сама.
Фразы вида "много внешних разработчиков" - это ни о чем. Я вам пишу про явные проблемы. Достаточно взглянуть на документацию, подумать как это работает, и все очевидно станет. Какие заплатки делают другие разработчики я не знаю. Но я вам предлагаю убрать подход с заплатками и сделать коннектор нормальным. Чтобы его логика работы было детерминированной. Я вам ранее уже писал о проблеме http://www.transaq.ru/forum/index.php?topic=1258.0 после чего вы изменили ТКоннектор (неправильно, конечно, сделали, но хоть так, иначе с ММВБ было вообще не возможно работать). Предлагаю и в этот раз сделать фикс. Только вначале скажите, как вы хотите его сделать. Чтобы не было как с кодами площадок.
-
Михаил, спасибо за настойчивость
Доработали UnInitialize , теперь dll должна выгружаться нормально
Кстати, чтобы отключить авто-переподключение можно в команде "connect" задавать значение session_timeout меньше, чем значение request_timeout
-
Хочу ответить, что до сих пор не работает. После того как вы отписали, еще 2 раза мне через личку давали 2 неработающие версии.
-
Михаил, чем закончилась эта история ?
Получается что при работе с транзак-коннектором совместно с S#-библиотекой могут быть проблемы.
-
Проблемы в библиотеке. Она не дает корректно завершать работу. Поэтому и коннектор наш не отключается.
Вообще складывается впечатление, что процесс разработки коннектора какой-то не отлаженный. Все на коленках. Мне в личку шлют сборки, которые просят меня же тестировать. При первом же запуске выясняется, что проблема не устранена. Далее опять мне что-то новое шлют. Сами шлют опровержения о том, что новый патч тоже не работает.
Видимо никто из пользователей не дошел дальше подключения. Я пытался местному руководству намекнуть, что пользователей у их решения раз два и обчелся, но они как-то это все мимо ушей пропускают. Хорошее решение, перспективное. А пользоваться проще кривым Квик апи, которым АПИ то с натяжкой можно назвать.
-
Ошибку в UnInitialize исправили.
Ошибка действительно была, исправляли ее достаточно долго - этого отрицать не стану. На то были свои причины. Но фактом также является то, что с данной ошибкой к нам, действительно, кроме вас никто не обращался. Собственно поэтому, именно к вам и обращались с просьбой подтвердить ее исчезновение.
Насчет того, что никто из пользователей не дошел дальше подключения вы заблуждаетесь.
С уважением,
Алексей
-
Это хорошо, что исправили. Спасибо. А где теперь скачать последнюю версию коннектора?
P.S. я зашёл намного дальше подключения )) можете писать с техподдержку финама - там если что подскажут и помогут
-
Скачать версию 2.7 можно здесь:
http://www.transaq.ru/cl_files/v508/508TXmlConnector_b2.7.zip
-
Попробуйте выключить всё что есть в трее, о потом завершить работу. Возможно сопротивляется какая-то программа.
-
Добрый день!
Подтверждаю некорректность завершения программы при осуществлении UnInitialize() в процессе приема данных с сервера.
Пишу С++, многопоток.
При осуществлении Закрытия соединения и последующей РазИнициализации библиотеки происходит ошибка неверного обращения к памяти (в моем понимании вещь заурядная, в ситуации когда потоки не синхронизированы).
Может быть стоит наделить функцию UnInitialize() желанием проверять завершился ли CallBack и только после этого чистить память?
-
Какая версия у вас? Uninitialize синхронизирован с потоком колбэков.
-
Какая версия у вас? Uninitialize синхронизирован с потоком колбэков.
Из файла: 20210521_dsp.log: 004435.224363 [27008] [25216] <info> System version 6.19. TXmlConnector version 2.21.8
Часть лога:
005845.121939 [27448] [34564] <cmd> <command id="disconnect"/>
005845.393297 [27448] [34564] <res> [R] <result success="true"/>
005845.793184 [27448] [clbk] <info> - [1300779u] <securities><security secid="1112" active="true"><sec_tz><![CDATA[Russian Standard Time]]></sec_tz><seccode>CH165000BU1</seccode><instrclass>O</instrclass><currency>RUR</currency><board>OPT</board><shortname>CHMF-9.21M150921PA165000</shortname>...
-
Пришлите пожалуйста полные логи dsp, ts, xdf на support@transaq.ru. Обработка колбэка длиной в 1300779 микросекунд уже не есть хорошо. Надо посмотреть при каких обстоятельствах возникает проблема. Минидампов случайно нет в папке с коннетором? Если есть пришлите их тоже.
-
Обработка колбэка длиной в 1300779 микросекунд уже не есть хорошо. Надо посмотреть при каких обстоятельствах возникает проблема.
Обработка такая короткая, по той причине, что она произошла в момент, когда основная программа уже была не в памяти (завершилась, и выгружена из памяти), что и вызвало ошибку обращения.