[jboss-jira] [JBoss JIRA] Commented: (JGRP-1025) Harden FLUSH

Bela Ban (JIRA) jira-events at lists.jboss.org
Thu Aug 20 15:33:24 EDT 2009


    [ https://jira.jboss.org/jira/browse/JGRP-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12482058#action_12482058 ] 

Bela Ban commented on JGRP-1025:
--------------------------------

[applies to merging as well)

- The flush should always be started by the coordinator, or at least by someone in the cluster, but never by a client (as in the state transfer)
- A flush should carry a flush-id, which includes the address of the flush leader and an ID
- A flush of an already flushed node with the same flush-id succeeds and is a no-op
- A flush of a locked node with a different flush-id is rejected
- Only the flush leader which started the flush can release the locks
- On view changes, we unlock all the flushes which have a flush-id of a crashed member
- Second line of defense: start a background task which periodically checks if all locked nodes's flush-ids are still alive members

> Harden FLUSH
> ------------
>
>                 Key: JGRP-1025
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1025
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.9
>
>
> Make sure no FLUSH is left hanging, e.g. due to the crash of the flush leader after the START-FLUSH round.
> In other words, make analyze the code and make sure STOP-FLUSH is eventually called.

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

        



More information about the jboss-jira mailing list