[
https://issues.apache.org/jira/browse/QPID-6996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15096253#comment-15096253
]
Keith Wall commented on QPID-6996:
----------------------------------
The underlying issue is that BDBHAVHN and BDBHARRN have {{role}} defined as a
ManagedAttribute and the field itself {{ManagedAttributeField}} and then cause
{{_role}} to be updated (asynchronously) without the knowledge ACO. This
allows the inconsistency to form. This usage is an abuse of the ACO framework.
Really the attribute {{role}} should be a {{DerivedAttribute}} which reflects
the node's current role in the group. Updates to the role should be made as an
operation rather than as an update, perhaps BDBHAVNH#requestMakeMaster. This is
an API change and will need to await a major release to do both parts.
In the short term (v6.0.x/v6.1.x), there doesn't appear to be an easy
workaround. The least unattractive hack seems to be to have
ACO#changeAtrributes() call #getActualAttribute and increate the visibility of
#getActualAttribute to protected so that BDBHAVH/BDBHARRN can override to
return the correct value in the case of ROLE.
> Can't change make a node master twice
> --------------------------------------
>
> 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
>
> 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
> affected by this defect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
