[
https://issues.apache.org/jira/browse/SSHD-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431934#comment-16431934
]
Goldstein Lyor commented on SSHD-812:
-------------------------------------
[~gnt]
{quote}
The first 3 commits could be merged without changing the logic from synchronous
to asynchronous,
{quote}
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
(v7.6.3#76005)
