unsubscribe

Best regards,
Eugene Petrenko

On Sun, Apr 8, 2018 at 11:24 PM, Guillaume Nodet (JIRA) <j...@apache.org>
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)
>

Reply via email to