-
Type:
Task
-
Status: QA Backlog
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 7.1.0
-
Fix Version/s: 7.1.0
-
Labels:None
-
Epic Link:
-
Story Points:3
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-5682have been reverted - an upgrade tasks has been added
- relates to
-
OPENDJ-7220 rest2ldap deadlock during (reverse) reference resolution
-
- Done
-
-
OPENDJ-6107 performance regression with shared connection pool
-
- Done
-
-
OPENDJ-5682 Add a SharedConnectionPool to reduce number of connections
-
- Done
-
- mentioned in
-
Page Loading...