The current implementation of the connection pool pushes on to the end of a list when a socket has been made available for re-use and pops off the same end when it's time to acquire. If I understand the code, the only way for a socket to be removed from the pool completely is for it to be popped off the queue, and used past it's timeout interval.

This has the effect of leaving the oldest sockets at the beginning of the pool, possibly to remain open and never be used again. The issue I'm experiencing is that when I do a code push and restart my web server, there is "massive" concurrency right away. This morning for example, my 4 connection pools (4 web server processes with individual pools) grew to a size of ~1400 within five minutes, stabilized, and never came down. The added burden of increasing the number of connections at the MongoDB end seems to also slow the system down to a degree, in turn, causing longer requests and even more concurrency.

If you have a large spike in traffic, should these old open sockets really hang around without being closed? One way to get around this would be to make the pool a dequeue, instead of a list. When you acquire a pooled socket, you could .popleft() it, which would have the effect of sharing the oldest sockets first. It'd certainly result in more AutoReconnect errors, but it seems pretty critical that they be handled anyway.