activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (AMQ-6088) Runtime configuration does not properly apply policy updates
Date Mon, 14 Dec 2015 19:06:46 GMT


ASF subversion and git services commented on AMQ-6088:

Commit 9e7fae0d83c584f98e99024ba6d20e53f14b81f7 in activemq's branch refs/heads/master from
[;h=9e7fae0 ]

The runtime plugins will now find the exact policy to update which means
that a destination can match more than one policy and the policy can
still be updated at runtime.

The java runtime broker also supports the ability to replace or add a
policy entry based on a flag on a new method call.

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