1) asyncMaxCommands is enforced for the entire cluster. That documentation blurb is also correct, but could be misinterpreted.
If a large block of commands were exlusively sent to the same node, then that large block would ultimately result in that node’s connection pool being filled to a limit of asyncMaxCommands.
Then, another large block of commands is exlusively sent to the another node. That node’s connection pool would also fill up to a limit of asyncMaxCommands. Repeat this process for all nodes in the cluster.
Since connections will not be dropped from the pools, the total number of open connections (including connections in the pools) is indeed limited by “asyncMaxCommands * nodeCount”.
In most cases, node distribution is more even, so the total number of open connections will be less than the theorectical max.
My original statement in this thread should have pointed out that even though each active command contains one connection, there will be more connections used than commands because of the extra connections stored in the connection pools.
2) sleepBetweenRetries makes sense for sync commands because the sleep is performed in parallel by multiple threads. The retry sleep time when a node goes down would be sleepBetweenRetries even when running 100 concurrent threads.
sleepBetweenRetries does not makes sense for async commands because the sleep is performed in series for each async event loop thread. If a node goes down, the first async command to that node would sleep for sleepBetweenRetries, then the next command would sleep and so on in sequence. This would result in huge client downtimes even when the node comes back up because existing async command sockets will not be reopened until they fail and sleep.
Yes, it is better to avoid internal client retries completely in async mode. If a command really needs to be retried, then it can be placed on an external retry queue that is controlled and processed by the user.