[
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: [email protected]
For additional commands, e-mail: [email protected]
