Hi Team, Could you clarify how SSH connection pooling works in SnapLogic? Is an SSH connection pool created per pipeline execution, or does each SSH-enabled Snap create and manage its own separate connection pool within a pipeline run?
Thank you for your question. SnapLogic pools SFTP sessions at the node (JVM) level. It does not create a pool per pipeline execution, and each SSH/SFTP-enabled Snap does not manage its own separate pool. Scope • Session pooling applies primarily to Binary Snaps (for example File Reader, File Writer and Directory Browser) when they use the SFTP protocol. Hadoop Snaps may also use it. • The pool is per node, not per Snaplex. Pipelines and Snaps running on the same node share it. How it works 1. A Snap obtains a session to the SFTP server, then opens a channel on that session. 2. Pooling is enabled by default. Sessions are keyed on server credentials: host, port, username and password. Snaps that connect with the same credentials can reuse a session, even if they use different SnapLogic accounts. 3. If an idle session is available, it is used. A session found to be dead is discarded and the next idle session is tried. If none are active, a new session is created. After use, the session returns to the cache. 4. By default each session carries one channel, so one session cannot serve multiple Snaps at the same time. Concurrent Snaps with the same credentials therefore open separate sessions unless the channel limit is raised. 5. A session idle past its timeout is discarded. Configuration (JVM options on the node) • cacheSftpSessions: set to false to disable pooling (default: enabled). • maxSftpChannels: maximum channels per session. The default is 1. Raise it to let one session be shared by multiple Snaps at once. • sftpSessionTimeoutSec: idle timeout after last use (default 3600 seconds, i.e. 1 hour).
We are experiencing intermittent failures while writing files from SnapLogic to the target SFTP server. The errors observed are:
SSH_MSG_DISCONNECT : 11
Connection closed by foreign host
The file transfer process follows these steps:
Read file from source.
Write file to a temporary target directory.
Move the file from the temporary directory to the final target directory.
Archive the source file.
The failures are occurring during interactions with the target SFTP server. The target team mentioned they have seen similar issues in the past and suspect they may be caused by multiple simultaneous connections, while their server is configured to support only a single connection at a time. A few questions:
How quickly is an SFTP session returned to the idle pool and made available for reuse by another Snap?
Are there any logs, metrics, or debug settings available to determine whether an existing session is being reused or a new session is being established?
Is it possible to configure maxSftpChannels at the Snap or Account level? We have maxSftpChannels set to 5.
If the target server only supports a single connection, are there any recommended SnapLogic configuration changes or best practices to minimize connection contention?
Any additional suggestions or recommendations for troubleshooting or resolving this issue would be greatly appreciated.
