tree 4758e4c5b5bbef404d27fd7a2eb76e52ec3d0c15
parent f1994bd3bee631ae828def8fe9e9ab35310da8cd
author Thomas Wolf <twolf@apache.org> 1684672035 +0200
committer Thomas Wolf <twolf@apache.org> 1685361748 +0200

GH-371: Re-implement the channel pool of an SftpFileSystem

The previous implementation always put unused SftpClients back into
the pool, but SftpClients in the pool were never closed (unless the
whole SSH session was closed).

Let this pool work more like a Java thread pool: besides a maximum
size, give it a minimum "core" size, and a maximum life time for idle
channels in the pool, and remove them from the pool and close them
when they expire. By default, the maximum pool size is 8, the core size
1, and the idle life time 10 seconds.

Also drain the pool when the file system closes, and close all channels.

Remove the ThreadLocal. This mechanism was questionable anyway; it was
the source of multiple earlier bug reports and there are some scenarios
that it just cannot handle correctly. This change will mean that an
application using more threads on an SftpFileSystem instance than the
pool size may see poor SFTP performance on the extra threads. In this
case, the pool size should be increased, or the application redesigned.

Add some technical documentation on all this.

Ensure in SftpFileSystem.readDir(String) that the SftpClient on the
SftpIterableDirEntry is the wrapper. We don't want to close the
underlying pooled channel. Ditto for InputStream and OutputStream
returned from read or write: those also must use the wrapper to react
properly when the wrapper is closed.

Ensure the behavior of an SftpDirectoryStream is correct when the stream
is closed. According to the javadoc on DirectoryStream, the iterator may
continue to produce already cached entries, but then may exhaust early.

Bug: https://github.com/apache/mina-sshd/issues/371