[
https://issues.apache.org/jira/browse/BOOKKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098034#comment-13098034
]
Ivan Kelly commented on BOOKKEEPER-59:
--------------------------------------
Hmmm, this is correct, so it should be safe to just remove the call to connect.
I'll upload a new patch which makes it more explicit though.
PerChannelBookieClient#connect is now private and synchronized. The
synchronization won't hit performance because the only call to #connect is
already in a synchronized block. However if someone makes the call from
somewhere else in the future, it'll still be safe.
PerChannelBookieClient#connected and
PerChannelBookieClient#connectionAttemptInProgress have been rolled into one
enum, as these are mutually exclusive states.
I've moved the check of PerChannelBookieClient#connectionAttempt into
#connect() as this seems like a better place for it.
> 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,
> 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
