[
https://issues.apache.org/jira/browse/BOOKKEEPER-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448216#comment-13448216
]
Sijie Guo commented on BOOKKEEPER-393:
--------------------------------------
ah, yes. I had observed the same issue when I were working on BOOKKEEPER-70. It
is safe the remove the closeSubscription call when processing unsubscribe
request, since all the unsubscribe requests have been guaranteed to be sent
only after local subscriptions are closed.
> Double-close of HedwigSubscriber channel
> ----------------------------------------
>
> Key: BOOKKEEPER-393
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-393
> Project: Bookkeeper
> Issue Type: Bug
> Components: hedwig-client
> Reporter: Stu Hood
>
> In HedwigSubscriber, calling unsubscribe():
> # calls closeSubscription() synchronously, which removes the subscriber's
> channel for the topic
> # asyncSubUnsub uses the _publisher's_ channel to send the UNSUBSCRIBE
> message, which bypasses the missing subscriber channel
> # (later, when the UNSUBSCRIBE response arrives)
> UnsubscribeResponseHandler.handleUnsubscribeResponse calls
> closeSubscription() again, which fails to find the previously closed channel
> with a warning:{noformat}WARN - [New I/O client worker
> #2-2:HedwigSubscriber@759] - Trying to close a subscription when we don't
> have a subscribe channel cached for topic
> {noformat}
> In the case described above, the double-close is harmless. But it's easy to
> imagine another situation where a client re-subscribes after unsubscribing,
> and the async closeSubscription described above causes their _new_ channel to
> be closed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
