[
https://issues.apache.org/jira/browse/BOOKKEEPER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093575#comment-13093575
]
Ivan Kelly commented on BOOKKEEPER-55:
--------------------------------------
This still isn't quite safe. What happens if after the check for the channel's
existence, a subscribe succeeds and sets the the channel for the topic? You'll
be put in the same situation again. And this time it will hit much less
frequently as the time window is smaller, making this a really painful race
condition to track down.
I think we need some sort of atomic check and set for the topic -> channel map.
This might require a bit of rearchitecting on the client though :/.
Also, a test for this would be nice.
> SubscribeReconnectRetryTask might retry subscription endlessly when another
> subscription is already successfully created previously
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: BOOKKEEPER-55
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-55
> Project: Bookkeeper
> Issue Type: Bug
> Components: bookkeeper-client
> Affects Versions: 3.4.0
> Reporter: Gavin Li
> Fix For: 3.4.0
>
> Attachments: patch
>
>
> For channelDisconnected envent, we try to automatically recover the
> connection and subscription. But when users call HedwigSubscriber.subscribe()
> at the same time, it might succeed before the auto recovery. Then the auto
> recovery can never succeed as the server will report topic busy failure. Then
> the SubscribeReconnectRetryTask will retry again and again endlessly. We
> found this in our auto test.
> Fix is easy, we just need to firstly check if the channel for this topic and
> subscribe id is null, if not it means some subscription is already created
> before, we don't need to bother recover.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
