ZOOKEEPER-4293: Lock Contention in ClientCnxnSocketNetty (3.5.x)#1713
ZOOKEEPER-4293: Lock Contention in ClientCnxnSocketNetty (3.5.x)#1713MikeEdgar wants to merge 2 commits intoapache:branch-3.5from
Conversation
|
@maoling, would you mind doing a review of this change? It resolves a lock contention situation where a slow connection allows the client's SendThread to enter The fix is to allow the |
|
@MikeEdgar I will take a look. Thanks for your contribution. |
|
@MikeEdgar Sorry for our late, I'll take a look at this weekend. Thanks for your reminder |
eolivelli
left a comment
There was a problem hiding this comment.
do we have a way to test this fix with an unit test ? (even with Mockito)
I am open to suggestions on an approach... Since this is dealing with thread timing, my solution to test it during development was with the debugger and breakpoints to simulate latency, which I understand is not ideal. Are there any other test cases that might deal with similar concepts? |
Check for failed/cancelled ChannelFutures before acquiring `connectLock` Signed-off-by: Michael Edgar <medgar@redhat.com>
931d28a to
99b7b00
Compare
|
@eolivelli , @maoling - I've finally added some tests with mocked dependencies. Please take a look. Also, this is for the 3.5 branch - should I instead replace the PR with one for |
|
@maoling - please let me know if this PR is OK as-is or if it should target |
Check for failed/cancelled ChannelFutures before acquiring
connectLock. This prevents lock contention where cleanup is unable to complete.Signed-off-by: Michael Edgar medgar@redhat.com