pub struct SshPool { /* private fields */ }Expand description
Connection pool for managing multiple SSH connections.
Implementations§
Source§impl SshPool
impl SshPool
Sourcepub fn new(options: SshOptions) -> Self
pub fn new(options: SshOptions) -> Self
Create a new connection pool.
Sourcepub async fn get_or_connect(
&self,
config: &WorkerConfig,
) -> Result<Arc<RwLock<SshClient>>>
pub async fn get_or_connect( &self, config: &WorkerConfig, ) -> Result<Arc<RwLock<SshClient>>>
Get or create a connection to a worker.
Validates transport liveness on borrow. The client detects exited or expired local masters, but a running master can still have a broken or stalled remote transport. Probe before reuse and reconnect once under the per-worker write lock if the transport no longer answers.
Sourcepub async fn active_connections(&self) -> usize
pub async fn active_connections(&self) -> usize
Get the number of active connections.
Sourcepub async fn run_with_timeout(
&self,
config: &WorkerConfig,
command: &str,
command_timeout: Duration,
) -> Result<CommandResult>
pub async fn run_with_timeout( &self, config: &WorkerConfig, command: &str, command_timeout: Duration, ) -> Result<CommandResult>
Run a single command on a worker over a POOLED (warm, reused) connection,
bounded by command_timeout.
This is the entry point daemon subsystems use instead of the throwaway
SshClient::new().connect()...execute()...disconnect() dance. It
get_or_connects a live master (validating
liveness on borrow and reconnecting a dead one), runs exactly one command,
and — crucially — does NOT disconnect afterwards, keeping the
ControlMaster warm for the next call. That is the whole point: reuse one
master per worker instead of spawning (and, under the old code, leaking) a
fresh master for every telemetry/health/cleanup poll.
The per-command timeout is applied via a temporary SshOptions override
on the pooled client so it does not disturb the pool’s shared default
(e.g. a long build vs. a short health probe). The connect timeout and
control-master/persist settings come from the pool’s options — except
that Windows workers are ALWAYS non-mux (see [pooled_client_options]):
Windows OpenSSH cannot multiplex, so a pooled mux session hangs at the
command stage.