[
https://issues.apache.org/jira/browse/SSHD-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16433856#comment-16433856
]
Guillaume Nodet commented on SSHD-812:
--------------------------------------
But in the light of allowing asynchronous processing, it does not make any
sense to return something, because it forces the code to actually fill it, thus
voiding any asynchronous processing imho.
I'm all for a single point in the code where the answer is sent back (or
queued), but it can't be the return value of the {{process()}} method if we
ever want to support aync.
An example would be if using an implementation using an AsynchronousFileChannel
: we can't return a value unless we force a synchronous behavior.
Even if not going fully async, but using different threads could be done, but
we definitely don't want to force a meaningful return value for {{process}}.
For example, we could have {{process}} queue {{Buffer}}s to be processed and
have a single additional thread that would dequeue them and process them one by
one (so in order, avoiding any out-of-order issue), then queueing the response
buffers to be send, and have a third thread dequeuing the buffers and writing
them to the output stream.
Here's an experiment I did yesterday:
https://github.com/gnodet/mina-sshd/commit/a4e40e4242af6c9987f127e74c21db989aee9950
This is just an idea so that we can discuss, not a PR.
In the above, the {{process}} method is not changed, i.e. it's fully
responsible for handling the incoming requests. However the code is modified
so that the processing of a requests decode the input buffer parameters and
call either {{submitPath}} or {{submitHandle}} with a {{Runnable}} that will
perform the i/o and prepare the output buffer.
It's still not optimal, as ideally, we'd use {{Supplier<SshFuture>}} that
would allow to add a listener which would sent the {{Buffer}}.
Fwiw, the {{submitPath}} or {{submitHandle}} are central interception point so
that advanced locking mechanism can be implemented: i.e. those 3 methods can
either:
- process synchronously
- enqueue everything in a single queue
- delegate to a thread pool, taking care of processing the operations
sequentially when this is necessary because the paths overlap with a previously
queued request
> 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)
