unsubscribe Best regards, Eugene Petrenko
On Sun, Apr 8, 2018 at 11:24 PM, Guillaume Nodet (JIRA) <[email protected]> wrote: > > [ https://issues.apache.org/jira/browse/SSHD-812?page=com. > atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=16429898#comment-16429898 ] > > Guillaume Nodet edited comment on SSHD-812 at 4/8/18 9:23 PM: > -------------------------------------------------------------- > > This would not solve the initial problem, as the reads from a single > handle would still be synchronized, so this would give no benefit as to > reading multiple parts of a single file concurrently. > > An optimization to consider, and maybe more important, would be to have > the subsystem implement {{AsyncCommand}} instead of the simple {{Command}} > and make sure we're using the async capability of the output stream. > > {code:title=main} > Buffer cmd = readCommand(in); > process(cmd); > {code} > > {code:title=doRead} > Handle h = handles.get(handle); > FileHandle fh = validateHandle(handle, h, FileHandle.class); > getExecutor(fh).execute(() -> { > fh.read(...) > asyncOut.writeBuffer(buffer); > }); > {code} > > This way, if the executor is designed correctly, we'd have a single thread > processing all the read operations sequentially on a given file, and > asynchronously writing the output, thus avoiding the cost of writing to the > socket to slow down the reads, as {{writeBuffer}} returns immediately, > without waiting for the write to be finished. > > > was (Author: gnt): > This would not solve the initial problem, as the reads from a single > handle would still be synchronized, so this would give no benefit as to > reading multiple parts of a single file concurrently. > > An optimization to consider, and maybe more important, would be to have > the subsystem implement {{AsyncCommand}} instead of the simple {{Command}} > and make sure we're using the async capability of the output stream. > > {code:title=main} > Buffer cmd = readCommand(in); > process(cmd); > {code} > > {code:title=doRead} > Handle h = handles.get(handle); > FileHandle fh = validateHandle(handle, h, FileHandle.class); > getExecutor(fh).execute(() -> { > fh.read(...) > asyncOut.writeBuffer(buffer); > }); > {code} > > This way, if the executor is designed correctly, we'd have a single thread > processing all the read operations sequentially on a given file, and > asynchronously writing the output, thus avoiding the cost of writing to the > socket to slow down the reads. > > > support asynchronization mode for sftp subsystem > > ------------------------------------------------ > > > > Key: SSHD-812 > > URL: https://issues.apache.org/jira/browse/SSHD-812 > > Project: MINA SSHD > > Issue Type: New Feature > > Affects Versions: 1.7.0 > > Environment: java1.8, linux > > Reporter: Zhenliang Su > > Assignee: Goldstein Lyor > > Priority: Minor > > Labels: asynchronous, sftp > > Attachments: Main.java, doRead.png > > > > > > I used SSHD as a middleman between client and target sftp server. > > I found that, when filezilla client directly connect to the target sftp > server, it transfers fast. When filezilla client connect to the middleman, > it transfers slow. > > I analyzed the source code of org.apache.sshd.server. > subsystem.sftp.SftpSubsystem#doRead, and I found it behaves > like block mode, and client's other SSH_FXP_READ request blocked in the > same thread. > > > > my middleman code: > > [^Main.java] > > > > > > -- > This message was sent by Atlassian JIRA > (v7.6.3#76005) >
