[jira] [Updated] (BOOKKEEPER-507) Race condition happens if closeSubscription and subscribe happened at the same time (in multiplexed client).

["Sijie Guo (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/BOOKKEEPER-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sijie Guo updated BOOKKEEPER-507:
---------------------------------

    Attachment: BOOKKEEPER-507.diff

> the non-callback startServingSubscription method is never called. 

removed.

> Shouldn't the wakeupLatch.countDown() call come after the closeLatch.await call?

closeSub would never succeed until delivery manager thread is waken up to process stopServingSubscriber requests.

for the original implementation, subscribe responded w/o waiting #startServingSubscription. so when the test case slept delivery thread manager for seconds, the subscribe request responded before close subscription requests. after the delivery manager thread wake up, the close subscription executed and responded, it would clear the state of succeed subscribe request.

> the spacing of the added code in SubscribeHandler is not correct.

It seems that it was all 4 spaces indent. Do you mean 8 spaces indent when folding parameters for #startServingSubscription?

> Should we raise them a bit, to say 5+ seconds

Increased the timeout of operations to 5 seconds.

>  but this TODO "// TODO make use of these variables" does not seem to make sense

I am not sure about this "TODO", seems that it existed for a long time. And it doesn't make any sense now. just remove it.

> To what operation is this comment referring to exactly

refactor the comments.

> "Should receive the message for a succeed subscriber."

made the change as the suggestion.
                
> Race condition happens if closeSubscription and subscribe happened at the same time (in multiplexed client).
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: BOOKKEEPER-507
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-507
>             Project: Bookkeeper
>          Issue Type: Bug
>            Reporter: Sijie Guo
>            Assignee: Sijie Guo
>            Priority: Blocker
>             Fix For: 4.2.0
>
>         Attachments: BOOKKEEPER-507.diff, BOOKKEEPER-507.diff, BOOKKEEPER-507.diff, subscribeshouldrespondafterstartserving.patch
>
>
> 1) closesub first
> 2) sub late
> 3) closesub succeed, but response is delayed to client.
> 4) since closesub succeed in server side, so sub succeed and tried to deliver message.
> 5) sub response is back
> 6) client checked and found that there is already a subscriber there.
> 7) client failed the subscribe request
> 8) but the message would still be delivered to same channel. since the sub state is not be cleared. message is still be received.
> 9) closesub response is back.
> 10) it clear the subscribe state.
> 11) message continue delivering but found there is no subscriber state.
> at step 11) the problem happened.
> this race condition is introduced in multiplexed client (BOOKKEEPER-70).

--
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