Guillaume Nodet commented on SSHD-812:

One thing I fear by not ordering the requests properly is that the subsystem 
will process the requests out of order:

read, id:4, offset=0, length=32768
read, id:6, offset=65536, length=32768
read, id:5, offset=32768, length=32768

If that happens, it may actually slow down the reading process because of the 
repositioning inside the file before reading.
I remember when I implemented the initial sftp substem that making sure the 
file stays open and that we don't have to seek is key to optimizing the reads.

So while I can agree that AsyncCommand would require lots of changes, and don't 
have any problem with a compromise solution, I think your proposed design needs 
to be improved so that the commands on a give handle can be executed in order.

Actually, the more I think about it, the less I see a good solution to process 
the requests concurrently (and that includes my earlier proposal): some 
requests do not need a FileHandle and can't be easily synchronized:
  - create directory
  - create empty file
  - delete file
  - delete directory
None of those 4 commands would be synchronized, and if processed out of order, 
one of them will fail.

So I'm not really sure we are able to process any requests concurrently, unless 
we implement a sophisticated locking mechanism on top of the tree represented 
by the filesystem (which should be doable if we really want to).

On the other hand, implementing AsyncCommand should be fairly trivial, and 
could be mostly limited to rewriting the {{send(Buffer)}} method.
We could also simply use an executor to queue the calls to {{send(Buffer)}}.  
This may be the safest and quickest way...

> 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

Reply via email to