2010-03-18 5 views
2

ПРИМЕЧАНИЕ: В качестве примера я использую канал ssh_sftp, но я заметил такое же поведение при использовании разных каналов.Проблема остановки Erlang SSH-канала

После запуска канала:

{ok, ChannelPid} = ssh_sftp:start_channel(State#state.cm), 

(где см мой Connection менеджер), я выступаю операцию через канал. Скажи:

ssh_sftp:write_file(ChannelPid, FilePath, Content), 

Затем я останавливая канал:

ssh_sftp:stop_channel(ChannelPid), 

Так, насколько я знаю, канал выполнен в виде gen_server, я ожидал, что запросы будут последовательно;.

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

Если я не останавливаю канал явно, все работает нормально, и запись файла (или любая другая операция, выполняемая через канал) выполняется правильно. Но я бы предпочел не оставлять открытые каналы. С другой стороны, я бы предпочел не выполнять собственный обработчик приема, чтобы дождаться результата до остановки канала.

Возможно, у меня, наверное, нет ничего тривиального. У вас есть идея, почему это происходит и/или я могу это исправить?

Повторяю, ssh_sftp - всего лишь пример. Я использую свои собственные каналы, реализованные с использованием существующих каналов в приложении Erlang SSH в качестве шаблона.

+0

Я посмотрел на 'ssh_sftp.erl', но я не вижу, как write_file будет _not_ ждать, пока файл будет правильно написан. Случайное предположение: проверьте возвращаемое значение из ssh_sftp: write_file ... – legoscia

ответ

1

Как вы можете видеть в ssh_sftp.erl он принудительно убивает канал через 5 сек таймаута с выхода (Pid, убить) который прерывает процесс независимо от того, является ли это что-то обрабатывать или нет.

Связанная цитата из erlang man:

Если Причина атома убить, то есть, если выход (Pid, убивать) называется, untrappable сигнал выхода посылаются Pid, ​​который будет безоговорочно выйти с выходом причиной погиб ,

1

У меня была аналогичная проблема с ssh_connection: exec/4. Проблема в том, что эти модули ssh sibling (ssh_connection, ssh_sftp и т. Д.), Похоже, ведут себя асинхронно, поэтому закрытие канала ssh само закрывает текущее действие.

Варианты:

1) не закрывает соединение: это может привести к утечке ресурсов. Назначение моего вопроса here

2) После sftp введите функцию мониторинга, которая ждет, отслеживая файл, который вы передаете на удаленном сервере (проверка контрольной суммы). Это может быть основано на ssh_connection: exec и poll на файле, который вы передаете.Как только контрольная сумма будет соответствовать ожидаемому, вы можете освободить основной модуль