qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wall (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-6996) Can't change make a node master twice
Date Wed, 13 Jan 2016 14:27:39 GMT

    [ 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

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message