Description
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.
Attachments
Issue Links
- relates to
-
AMQ-5915 Support a Java API for the RuntimeConfigurationPlugin
-
- Resolved
-