Quoting Yannick Lecaillez:

I discovered recently in rest2ldap that connection sharing can lead to deadlock, see OPENDJ-7220.

SharedConnectionPool usage should probably be limited to use-case where we know we're not doing big searches. At least, until we have a protocol based on HTTP/2 or alike which do transmit the client backpressure constraints upstream.

To be complete, now quoting Matthew Swift:

Good question. I don't see much point in keeping the SharedConnectionPool if it is very risky to use and has limited use cases.

Care also needs to be taken with a CachedConnectionPool as well. Basically, don't use the same real connection for nested (joined) operations, or receive all the results first before performing the nested operations.

An alternative is to modify the SharedConnectionPool to treat non base object searches like bind operations by routing them to a dedicated connection (I only one concurrent search per connection). Unfortunately, it would mean that single entry searches would not be performed in parallel on the same connection and these are the operations most likely to benefit from the "shared" capability.

Acceptance criteria

This issue can be closed once:

• the SharedConnectionPool class has been removed
• all related code changes in OPENDJ-5682 have been reverted
• an upgrade tasks has been added