mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SSHD-394) Use an ExecutorService to spawn SftpSubsystem command
Date Tue, 13 Jan 2015 15:30:38 GMT

    [ https://issues.apache.org/jira/browse/SSHD-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275384#comment-14275384

Guillaume Nodet commented on SSHD-394:

The patch is problematic has the default behaviour (i.e. when not specifying an executor service)
will leak the thread pool executor.
For example running the SftpTest will lead to a number of threads pending (the executor is
not closed, so the thread created by the executor is not stopped either).

So we'd need an additional argument along the executor to tell the SftpSubsystem if it should
close the executor service or not, like done in AbstractFactoryManager#setScheduledExecutorService

Another possible way would be to add an ExecutorService to the ServerFactoryManager to be
used by commands and subsystems or directly by the ChannelSession to spawn threads for commands
and subsystems.
It's also slightly related to SSHD-297.

> Use an ExecutorService to spawn SftpSubsystem command
> -----------------------------------------------------
>                 Key: SSHD-394
>                 URL: https://issues.apache.org/jira/browse/SSHD-394
>             Project: MINA SSHD
>          Issue Type: Improvement
>    Affects Versions: 0.14.0
>            Reporter: Goldstein Lyor
>         Attachments: 0006-update1-SSHD-394-Use-an-ExecutorService-to-spawn-SftpSubsyst.patch
> The current code simply uses {code:java}new Thread(this).start(){code} This precludes
the user from configuring the thread's attributes - name, priority, stack size, thread-group
and most important whether it is a daemon or not. By allowing to provide an _ExecutorService_
we enable all these.
> *Note:* the choice for using an _ExecutorService_ rather than a simple(r) _Executor_
is twofold:
> # The documentation for _Executor#execute()_ clearly states: {panel}Executes the given
command at some time in the future.  The command may execute in a new thread, in a pooled
thread, or in the calling thread, at the discretion of the _Executor_ implementation.{panel}
> In our case we want to make sure that a *new* thread is spawned
> # The _ExecutorService#submit()_ call returns a _Future_ object which we can later use
to stop the command when the _destroy()_ method is called

This message was sent by Atlassian JIRA

View raw message