[jboss-jira] [JBoss JIRA] Resolved: (JGRP-842) GMS: graceful leave takes a long time

[Bela Ban (JIRA)]

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

Bela Ban resolved JGRP-842.
---------------------------

    Resolution: Done


Was caused by an FD_SOCK regression: even a graceful leave would trigger a suspect message, which needed to get handled by the coord, so the coord could only leave after that, which took some time.

> GMS: graceful leave takes a long time
> -------------------------------------
>
>                 Key: JGRP-842
>                 URL: https://jira.jboss.org/jira/browse/JGRP-842
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.7
>
>
> Scenario: 
> - A and B
> - B leaves gracefully
> - A leaves gracefully
> - It takes A GMS.leave_timeout ms to leave where the leave should be immediate
> Reason: we get a SUSPECT(B) event on A (see https://jira.jboss.org/jira/browse/JGRP-841) although B leaves gracfully. The GMS.ViewHandler has now a SUSPECT event in the queue, and we cannot leave until this event has been processed.
> SOLUTION:
> - Fix JGRP-841
> - Take a look at Channel.disconnect() and close(). Both call stopStack() regardless of whether it has already been called. This invoked stop() in all protocols, and GMS calls ViewHandler.stop(). This method doesn't check whether stop() has already been closed and adds a flush marked to the queue.
> This does not occur in the 2.6 branch.

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