ConcurrentUpdateSolrClient spins up background threads that pull documents from a queue and feed them into open HTTP connections. Before writing each UpdateRequest on the connection, CUSC checks that the SolrParams match the params used when originally opening the connection. But it doesn't check that the collection is the same.
If a user is using the same ConcurrentUpdateSolrClient to send documents to multiple collections simultaneously, each of their UpdateRequest might go to the wrong collection entirely, based on what connections are already open.
The problem can be reproduced with the snippet below. The correct behavior would be for 500 docs to go to each collection. But instead, on most runs all 1000 go to collection1.