qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-6996) Can't make a node master twice (during a single Broker lifetime)
Date Fri, 15 Jan 2016 15:47:39 GMT

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

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

View raw message