Connection Pool Implementation about sshkit

[leehambley]

I benchmarked the opening of SSH channels, here were the results, the connections for each were opened 1_000 times.

Rehearsal -------------------------------------------------
with ssh key    0.500000   0.090000   0.590000 (  7.526066)
with password   0.470000   0.100000   0.570000 (  7.342561)
---------------------------------------- total: 1.160000sec

                    user     system      total        real
with ssh key    0.510000   0.090000   0.600000 (  7.381403)
with password   0.500000   0.100000   0.600000 (  7.513771)

That tells me that it's fast enough, call it 0.007s (7ms) to open a connection, under good conditions, and it should be fast enough for a first implementation.

So saying that, let's say an implementation of on() might look like this:

def on(hosts, options = {}, &block)
  pool = ConnectionPool.new(hosts)
  pool.execute(&block, options)
  pool.terminate
end

[leehambley]

And further to that, a naïve pseudo implementation of ConnectionPool:

require 'net/ssh'

class ConnectionPool

  Error = Class.new(RuntimeError)

  attr_reader :members, :hosts

  def initialize(hosts)
    @hosts   = hosts
    @members = {}
  end

  def perform(&block)
    begin
      # Something here needs to support
      # parallel/sequential/limit/etc
      members.each do |host, session|
        yield host
      end
    rescue # Suitable Exception list here
      raise ConnectionPool::Error
    ensure
      terminate
    end
  end

  def terminate
    members.map(&:close)
  end

  private

    def open_connections
      begin
        hosts.each do
          members[host] = Net::SSH::Session.new(host)
        end
      rescue Net::SSH::Authentication::AgentError,
             Net::SSH::Authentication::KeyManagerError,
             Net::SSH::AuthenticationFailed,
             Net::SSH::ConnectionTimeout,
             Net::SSH::Exception 
             # Etcetera
        terminate
        raise ConnectionPool::Error            
      end
    end

end

With the beginnings of this in mind, I see the following problems:

1. I'm starting to dislike the name "ConnectionPool", as we're having stubbed/test backends, we should be careful to come up with a useful name that fits all the paradigms we care about. (HostPool?)
2. Further to the first point, It's not just a pool in my naïve implementation, it's also responsible for doing some work, this is a limitation of my spike in the Github issue, and something that we could solve by renaming/redesigning slightly (and I think we should)
3. I don't see a nice way to handle the parallel vs. sequential with(±out) limits here, again, splitting this functionality into two classes might be wise.
4. Maybe we could have something that checks-out connections from the pool, this could block until a connection is ready (pool would handle :limit) but the something would handle parallel vs. sequential. This something would then be responsible for threading, and/or forking. This way the parallel/sequential option is separated from the handling of the connections.