[
https://issues.apache.org/jira/browse/BOOKKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098019#comment-13098019
]
Flavio Junqueira commented on BOOKKEEPER-59:
--------------------------------------------
Suppose we remove the else block as I suggested. In this case, #connect is only
called through #connectIfNeededAndDoOp. In #connectIfNeededAndDoOp, only one
thread can call #connect at a time because of the synchronized block. If a
thread ends up executing #connectIfNeededAndDoOp concurrently with another
thread (connect hasn't completed for the latter thread), then #connect won't be
called because connectionAttemptInProgress == true.
Note that connectionAttemptInProgress is also set inside a synchronized block
in the callback of connect, so it doesn't sound like the race you're saying can
occur under the assumptions I stated.
What do you think? Am I missing anything?
> Race condition in netty code allocates and orphans resources (BK-5 revisited)
> -----------------------------------------------------------------------------
>
> Key: BOOKKEEPER-59
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-59
> Project: Bookkeeper
> Issue Type: Bug
> Reporter: Ivan Kelly
> Assignee: Ivan Kelly
> Fix For: 3.4.0
>
> Attachments: BOOKKEEPER-59.diff, BOOKKEEPER-59.diff
>
>
> We thought BK-5 fixed this, but it still hits if you run for long enough.
> To repro,
> true; while [ $? = 0 ]; do mvn test -Dtest=BookieReadWriteTest; done
> Leave this running for 5-6 hours, and the bug should hit. From looking at the
> code it could be that connect is unsynchronized, so resources could be
> allocated and lost by concurrent executions of connect().
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
