activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher L. Shannon (JIRA)" <>
Subject [jira] [Resolved] (AMQ-6088) Runtime configuration does not properly apply policy updates
Date Mon, 14 Dec 2015 19:22:46 GMT


Christopher L. Shannon resolved AMQ-6088.
       Resolution: Fixed
    Fix Version/s: 5.14.0

A policy can now be modified even if it matches more than one destination because the policy
will only be applied to the correct destination(s) during update.  This includes the case
of a new policy as well.  This applies to both the Java and XML runtime plugins.

Also, there's a new option in the Java plugin to create or replace (based on a flag) a policy
entry.  For the replace case, that is useful if someone wants to update a policy without looking
up the existing one first, which is required in the current version.

> Runtime configuration does not properly apply policy updates
> ------------------------------------------------------------
>                 Key: AMQ-6088
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.13.0
>            Reporter: Christopher L. Shannon
>            Assignee: Christopher L. Shannon
>             Fix For: 5.13.1, 5.14.0
> There is 1 bug and 1 improvement with policy modification at runtime with both the XML
runtime broker and Java runtime broker.
> For the bug portion, when a new policy is added there is no check to see if there are
any more specific policies that should be used.  So if a policy called "queue.test.child.>"
exists, and then a new policy for "queue.test.>" is added, this will update destinations
that match the more specific policy and it shouldn't.  There is a check for this for modification
(as seen below) but not on adding a new policy.
> For the improvement, when modifying a policy entry, an entry can only be modified if
there are no children entries.  This is a problem because if two policies exist, say for "queue.test.>"
and "queue.test.child.>", we can not modify "queue.test.>" because there is logic to
prevent this.  This is done to prevent reapplying changes to destinations that might be affected
by "queue.test.child.>".  (which breaks on an add)
> However, with the use of the policy map we should be able to update any policy and figure
out which specific destinations because we can look up whether or not the policy being updated
should be applied to the destination.  So this limitation should be removed and the proper
logic should be applied for both adding and updating policies.
> This should be merged into 5.13.1 because it's a bug fix and improvement to how policies
are applied.

This message was sent by Atlassian JIRA

View raw message