Goldstein Lyor commented on SSHD-812:

The first 3 commits could be merged without changing the logic from synchronous 
to asynchronous,
Let's do this then
* Add the commits that don't change the logic and don't add the whole 
{{AsyncCommand}} to the {{SftpSubsystem}})
* I will add the (synchronous) changes I think we should add - present it
* Commit whatever we decide
* Add/merge the asynchronous implementation as an *optional* "extended" 
{{SftpSubSystem}} in like I suggested

My concern is this - the asynchronous implementation adds a significant degree 
of uncertainty and instability to code that is basically very stable and 
reliable. We know that no matter how much testing we do, concurrent code is 
very difficult to test - especially subtle race conditions. E.g., my thinking 
is that until the {{SSH_FXP_INIT}} message is received and successfully 
processed we work in synchronous mode. Only after it we can spawn threads and 
work asynchronously. The rationale is that the initialization message sets the 
protocol version - which is a major cornerstone - and until that is done we 
risk an out-of-order sequence where user send {{INIT, OPEN, READ, CLOSE}} 
sequence, but because of concurrent execution, the sub-system might process 
{{OPEN}} before {{INIT}}. BTW, a similar race condition can occur if processing 
{{CLOSE}} before {{READ}}, but IMO it is the *client's* responsibility not to 
mess this sequence up The same might be said about {{INIT}} but I can totally 
see "smart" programmers deciding that they don't have to wait for the {{INIT}} 
response before issuing the next command since "it will most likely succeed, so 
why wait...".

The model I recommend opens up the option for having the concurrent code, but 
let's gain some experience with it before releasing it into the wild. I am more 
than willing to consider the following:

* Let's release the asynchronous implementation as the default
* Let's add a configuration value and/or other simple means by which if there 
is an issue, users can switch the old-and-trusted "legacy" synchronous code.

> support asynchronous 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