Problem statement

When a mongos is initially brought up, it lacks connections to any of the cluster’s shard servers. This can add latency to user operations, as we require a request to a host before we start spooling a connections (even in the presence of minPoolSize).

Proposal

Provide a new startup parameter, which would cause mongos wait a configurable amount of time to establish at least minPoolSize connections to each shard server before accepting user connections. This would allow us to reboot mongos’, or add new ones, without making any initial user requests pay the overhead of waiting on connection establishment.

This should should be relatively simple. Cribbing from the test only mongos command: multicast

1. Temporarily turn the host timeout to infinity
2. Fetch all shard ids
3. Foreach shard id
   1. Get the connection string
   2. Foreach host in the connection string
      1. Push the host onto a list
4. Use the AsyncMulticaster, with the arbitrary executor, to multicast a ping to all hosts
5. Wait for a configurable delay, periodically checking connpoolstats to see if hosts all have minPoolSize connections
   1. If all pools reach the desired size before the timeout, stop waiting
   2. If all pools don’t, continue at the end of the timeout
6. Return the host timeout to its former value
7. Start accepting client connections

Steps 1 and 7 may also be optional (if we’re waiting 10 seconds, the 5 minute host timeout may not matter).

In either case, the work should be relatively approachable, as it only involves being a regular client of the networking layer in mongos, rather than doing any development against the interior components.