[jboss-jira] [JBoss JIRA] (JGRP-2324) TransferQueueBundler: view change must not purge messages to non-members

[Bela Ban (Jira)]

     [ https://issues.jboss.org/browse/JGRP-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2324:
---------------------------
    Description: 
Currently, {{BaseBundler.viewChange()}} purges queued messages to non-members. This poses the following problem:
* Members A, B. The view is \{A,B\}
* A is coord and sends a LEAVE request to B
* B adds a LEAVE response (to A) to the TransferQueueBundler's queue and  installs new view \{B\}
* If the LEAVE response to A is still in the TQB's queue and the new view is installed _before_ the message gets sent, the {{BaseBundler.viewChange()}} method _removes_ all queued messages to non-members, therefore the LEAVE response to A is removed
* As a result, A will never receive the LEAVE response and therefore run into {{GMS.leave_timeout}}!

This is aggravated by the fact that a LEAVE response is unreliable (flag={{NO_RELIABILITY}}), and therefore not retransmitted by UNICAST3.

Solution: remove the {{viewChange()}} method.
Reason: 
* Unicast messages _can_ be sent to non-members. This is in line with the design of UNICAST3, which allows for non-members as destinations of messages.
* The {{msgs}} hashmap in {{BaseBundler}} will be emptied by the runner anyway, so we don't need to do housekeeping on that hashmap

  was:
Currently, {{BaseBundler.viewChange()}} purges queued messages to non-members. This poses the following problem:
* Members A, B, view is \{A,B\}
* A is coord and sends a LEAVE request to B
* B adds a LEAVE response (to A) to the TransferQueueBundler's queue and  installs new view \{B\}
* If the LEAVE response to A is still in the TQB's queue and the new view is installed before the message gets sent, the {{BaseBundler.viewChange()}} method _removes_ all queued messages to non-members, therefore the LEAVE response is removed
* As a result, A will never receive the LEAVE response and therefore run into {{GMS.leave_timeout}}!



> TransferQueueBundler: view change must not purge messages to non-members
> ------------------------------------------------------------------------
>
>                 Key: JGRP-2324
>                 URL: https://issues.jboss.org/browse/JGRP-2324
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Major
>             Fix For: 4.0.16
>
>
> Currently, {{BaseBundler.viewChange()}} purges queued messages to non-members. This poses the following problem:
> * Members A, B. The view is \{A,B\}
> * A is coord and sends a LEAVE request to B
> * B adds a LEAVE response (to A) to the TransferQueueBundler's queue and  installs new view \{B\}
> * If the LEAVE response to A is still in the TQB's queue and the new view is installed _before_ the message gets sent, the {{BaseBundler.viewChange()}} method _removes_ all queued messages to non-members, therefore the LEAVE response to A is removed
> * As a result, A will never receive the LEAVE response and therefore run into {{GMS.leave_timeout}}!
> This is aggravated by the fact that a LEAVE response is unreliable (flag={{NO_RELIABILITY}}), and therefore not retransmitted by UNICAST3.
> Solution: remove the {{viewChange()}} method.
> Reason: 
> * Unicast messages _can_ be sent to non-members. This is in line with the design of UNICAST3, which allows for non-members as destinations of messages.
> * The {{msgs}} hashmap in {{BaseBundler}} will be emptied by the runner anyway, so we don't need to do housekeeping on that hashmap



--
This message was sent by Atlassian Jira
(v7.12.1#712002)