[
https://issues.apache.org/jira/browse/BOOKKEEPER-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152763#comment-13152763
]
Sijie Guo commented on BOOKKEEPER-79:
-------------------------------------
Ivan, thanks for your comments. It is great that you tried to avoid callbacks
be triggered after stopReceiving in new patch. But a thread is introduced for
each channel, if we have lots of subscriptions we will have same number of
threads. it is not good.
Beside the number of threads issue, #stopReceiving will be blocked if no data
sent from server in the channel, since it only be notified in
messageCallbackHandler. async_read will not trigger the bound callback if no
data read from the channel.
I attached a new patch based on my previous comments, which can
1) ensure no callbacks after #stopReceiving, also ensure no message lost
between stopDelivery and startDelivery (add order checking in
MessageHandlerCallback)
2) avoid the deadlock on mutexes.
> randomly startDelivery/stopDelivery will core dump in c++ hedwig client
> -----------------------------------------------------------------------
>
> Key: BOOKKEEPER-79
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-79
> Project: Bookkeeper
> Issue Type: Bug
> Components: hedwig-client
> Affects Versions: 4.0.0
> Reporter: Sijie Guo
> Assignee: Sijie Guo
> Fix For: 4.0.0
>
> Attachments: BOOKKEEPER-79.patch_v2, BOOKKEEPER-79.patch_v3,
> bookkeeper-79.patch, pubsubtest.cpp
>
>
> in our test program, we tried to startDelivery/stopDelivery different
> subscriptions randomly. And it core dump.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
