|
Обмен между кодом на COS и внешним приложением.
|
|||
---|---|---|---|
#18+
Предисловие. Имеется DLL 32 бит и БД на Cache под 64 бит версией СУБД. Имеется некий код на COS в БД. Требуется вызвать DLL из СУБД. Если бы СУБД была 32 бит, то нет ничего проще - рисуем еще одну dll в понятном для Cache виде, которая уже вызовет нужную dll. В моем случае, похоже, придется делать отдельное приложение, вызывающее dll и как-то взаимодействующее с БД. Теперь, собственно, вопрос. Какой метод обмена между приложением и кодом в БД сейчас считается самым шустрым и самым стабильным. Пока в голову приходит только TCP сокет. А есть ли альтернативы этому методу? А может быть, есть иной способ обратиться к 32 бит DLL из 64 бит СУБД (с COM, .NET и проч. связываться по разным причинам не хочется)? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2013, 19:26 |
|
Обмен между кодом на COS и внешним приложением.
|
|||
---|---|---|---|
#18+
Лучше сокета, пожалуй, только перевод DLL на x64. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2013, 03:07 |
|
Обмен между кодом на COS и внешним приложением.
|
|||
---|---|---|---|
#18+
По некоторым причинам от сокета пришлось отказаться и переделать на пайп. После некоторых плясок с бубном все заработало, но остался один странный момент. Создаю пайп другим приложением, открываю его из кода на COS. Обмен идет без проблем, пока не делается единовременная запись в пайп более 512 байт. В этом случае чтение на внешней программе идет порциями по 512 байт, хотя функции чтения явно задается большее значение количества байт для считывания. Интересно, почему оно так? Вроде 512 не является каким-то стандартным ограничением на работу с пайпами, или где-то все же есть подвох? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2014, 20:51 |
|
Обмен между кодом на COS и внешним приложением.
|
|||
---|---|---|---|
#18+
Hisbreht VictorВроде 512 не является каким-то стандартным ограничением на работу с пайпами, или где-то все же есть подвох? ijcbuff (попробуйте ещё поиграться с параметрами IBUFSIZE/OBUFSIZE) PS: хороший пример работы с pipe можно найти в ##class(%Net.Remote.Utility).RunCommandViaCPIPE() ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2014, 13:28 |
|
Обмен между кодом на COS и внешним приложением.
|
|||
---|---|---|---|
#18+
servit ijcbuff (попробуйте ещё поиграться с параметрами IBUFSIZE/OBUFSIZE)Спасибо, попробую. Получается, что максимум может быть 8 К. А IBUFSIZE/OBUFSIZE вроде относится к созданию пайпа на стороне COS, т.е. вроде не мой случай. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2014, 19:30 |
|
Обмен между кодом на COS и внешним приложением.
|
|||
---|---|---|---|
#18+
Менял ijcbuff, ijcnum. Результата никакого. Передаются все те же порции по 512 байт. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2014, 20:03 |
|
Обмен между кодом на COS и внешним приложением.
|
|||
---|---|---|---|
#18+
Hisbreht VictorМенял ijcbuff, ijcnum. Результата никакого. Передаются все те же порции по 512 байт.Да, это не Ваш случай. Эти параметры используются только при межпроцессном обмене самой Caché. Сделал на COS небольшие сервер и клиент - ijcbuff учитывается. Hisbreht VictorПолучается, что максимум может быть 8 К.По крайней мере, для чтения из PIPE можно указать 3641144 включительно (по умолчанию используется 32767: Default Record Length ) Сделал два консольных приложения, выводящих в stdout одну большую строку, а в Caché её считываю. Чтение в Caché результата вывода консольного приложенияProject1.pas: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
test.vbs: Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
test.mac #Include %msql for размерПакета=512,8192,$$$MaxStringLength d $system.OBJ.DisplayError($$run(размерПакета,"Project1.exe 100000")) ; или for размерПакета=512,8192,$$$MaxStringLength d $system.OBJ.DisplayError($$run(размерПакета,"cscript.exe test.vbs 100000")) run(размерПакета, pCmd) { Set tSC = $$$OK Set pTimeout = 20 Set pTimeoutRead = 10 Set pOutput = "" Set пакет = 0 Set IO = $IO Set ZEOFMode = $ZU(68,40,1) Set pDevice = "|CPIPE|" Try { Open pDevice:(pCmd:"R"):pTimeout If '$T Set tSC = $$$ERROR($$$CacheError, "Failed to open |CPIPE| device in read mode for command: '"_pCmd_"'") Quit Use pDevice For { Set tLine = "" Read tLine#размерПакета:pTimeoutRead Quit:(($ZEOF=-1)||('$T && (tLine=$C(-1)))) //Exit by EOF/timeout Set пакет = пакет + 1 Set пакет(пакет) = $L(tLine) Set pOutput = pOutput_tLine } } Catch (ex) { Set tSC = ex.AsStatus() } Close pDevice If 'ZEOFMode Do $ZU(68,40,0) // Restore ZEOF mode Use IO Write !,$L(pOutput)," :",размерПакета,! ZWrite пакет Quit tSC } Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Но на всякий случай проверьте на стороне внешного приложения размер входных/выходных буферов при создании PIPE: Передача данных между процессами ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 13:26 |
|
Обмен между кодом на COS и внешним приложением.
|
|||
---|---|---|---|
#18+
Пайп создается в стороннем приложении вызовом CreateNamedPipe. Открывается в COS следующим образом (пишу по памяти, в деталях могу ошибиться): s io="имя пайпа" OPEN io:"RWUK\RAW\":2 Размер входного и выходного буфера пробовал всякий. Даже если они установлены больше 512 байт, один вызов ReadFile возвращает не больше 512 байт. Передачу большого объема в другую сторону еще не проверял. Пробовал на Cache 2008 и 2013. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 23:26 |
|
Обмен между кодом на COS и внешним приложением.
|
|||
---|---|---|---|
#18+
Получается. что код на COS вполне нормально отправляет большой фрагмент за один присест, не вопрос, но принимается он приложением, создавшим пайп, кусками по 512 байт. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 23:30 |
|
Обмен между кодом на COS и внешним приложением.
|
|||
---|---|---|---|
#18+
Hisbreht VictorПолучается. что код на COS вполне нормально отправляет большой фрагмент за один присест, не вопрос, но принимается он приложением, создавшим пайп, кусками по 512 байт.может дело в том приложении. Попробуй другие варианты. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 23:45 |
|
|
start [/forum/topic.php?fid=39&fpage=22&tid=1556940]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
26ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 130ms |
0 / 0 |