[ 
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