You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2016/01/15 16:47:39 UTC
[jira] [Commented] (QPID-6996) Can't make a node master twice
(during a single Broker lifetime)
[ https://issues.apache.org/jira/browse/QPID-6996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101949#comment-15101949 ]
ASF subversion and git services commented on QPID-6996:
-------------------------------------------------------
Commit 1724843 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1724843 ]
QPID-6996: Add tmp model feature that allows a attribute update to proceed even if its value is unchanged
The role attribute is special in that its local view get update sponantenously when an election occurs
in the group. We need a special model feature to allow an attribute update to proceed even if the model
believes the value already has the desired value.
> Can't make a node master twice (during a single Broker lifetime)
> ----------------------------------------------------------------
>
> Key: QPID-6996
> URL: https://issues.apache.org/jira/browse/QPID-6996
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: 0.30, 0.32, qpid-java-6.0
> Reporter: Keith Wall
> Priority: Minor
> Attachments: roleChangePatch.diff, roleChangePatch2.diff
>
>
> The Java Broker's BDB HA implementation permits the mastership to be transferred around the group. To initiate this change, a user mutates the model attribute "role" on object {{BDBHAVHN}} or {{BDBHARRN}} to have the value {{MASTER}} through a management interface.
> If I make this change once, the change is effective. If later the mastership moves again (as a result of a failure and subsequent election or a transfer master elsewhere in the group), the attempt to move the mastership back to this node is ignored (defect).
> The issue is that ACO#changeAttributes blocks the subsequent change because it does not know that attribute's value is anything other than {{MASTER}}. This is because BDBHAVHN#setRole (happens asynchronously as the mastership changes) updates only the CO view of the attribute (#_role), leaving ACO#_attributes.get(ROLE) with a stale value {{MASTER}}. The Broker containing the node needs to be bounce to correct the state problem.
> The main use-case for transfer master is to restore the master to its business as usual position following a device failure. This use-case is not affected by this defect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org