[jboss-jira] [JBoss JIRA] Commented: (JGRP-425) Incorrect state transfer in high contention scenarios

Bela Ban (JIRA) jira-events at lists.jboss.org
Wed Mar 7 08:16:22 EST 2007


    [ http://jira.jboss.com/jira/browse/JGRP-425?page=comments#action_12355286 ] 
            
Bela Ban commented on JGRP-425:
-------------------------------

Note: this problem only occurs in 2.5 where messages can bubble up the stack concurrently. Prior to 2.5, messages/events were dispatched sequentially up and down the stack, therefore the GET_DIGEST return event from NAKACK could not be 'passed' by any regular message

> Incorrect state transfer in high contention scenarios
> -----------------------------------------------------
>
>                 Key: JGRP-425
>                 URL: http://jira.jboss.com/jira/browse/JGRP-425
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5
>
>
> State transfer (with digests) works as follows:
> - State is requested from a provider
> - Provider (1) gets the digest from NAKACK (below) and then (2) the application state from the channel (above)
> - Between (1) and (2), some multicast message received can alter the state, as follows:
>   - Multicast message M is received
>   - At the same time, a state request is received
>   - To handle the state request, we ask NAKACK for the digest
>   - The digest contains M
>   - Now - before M is passed up - the digest is returned to STATE_TRANSFER and we fetch the state 
>     *WITHOUT* M ! When the state requester gets the state&digest, it will reject a resent M because it thinks
>     it is in its state (because it is in its digest), however M is not part of the state !
> Other issue:
> - M is received after the digest has been retrieved by STATE_TRANSFER, but then M passes the state transfer and is received by the channel and applied to the state *before* the state request can fetch the state. Now M is *not* part of the digest, but it *is* part of the state !
> SOLUTION:
> - When getting the digest, set a flag (in NAKACK) such that all subsequent multicast up-messages are blocked (or add them into a bounded FIFO list)
> - Fetch the state from the channel (the application)
> - Unblock NAKACK (send down an UNBLOCK event)
> - Return the state&digest to the state requester

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the jboss-jira mailing list