[ 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)