The connection pool has this interesting bit of code (https://github.com/mongodb/mongo-ruby-driver/blob/master/lib/mongo/server/connection_pool/queue.rb#L206):

        def close_stale_sockets!
...
                connection.disconnect!
                if queue.index(connection) < min_size_delta
                  begin; connection.connect!; rescue; end
                end

This causes, in my understanding, exposed by jruby:

1. Application creates new connections at a good rate (for example, when running scram negotiation_spec).
2. This causes there to be a large number of connections in the pool.
3. This triggers the staleness closure logic due to min_size_delta getting exceeded.
4. As part of closing the sockets, client establishes new connections to the server .

This causes the aforementioned scram negotiation test to fail in jruby because instead of expected one authentication attempt I am getting 2 or 3, for users that are defined in previously executed tests.

(This wouldn't be an issue if client instances weren't reused.)

Exposed by jruby which, I'm guessing unlike mri, is able to concurrently run tests and do SDAM as the clients are seemingly reconnected from monitor thread.