You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Johan Carlquist <jo...@su.se> on 2016/06/10 08:53:55 UTC
policyEntries, inheritance and wildcards
Hi!
Our config:
=====
[...]
<policyEntries>
<policyEntry queue=">" >
<networkBridgeFilterFactory>
<conditionalNetworkBridgeFilterFactory
replayWhenNoConsumers="true"
/>
</networkBridgeFilterFactory>
</policyEntry>
<policyEntry queue="just.another.queue">
<deadLetterStrategy>
<individualDeadLetterStrategy
processExpired="true"
processNonPersistent="true"
queueSuffix=".DLQ"
useQueueForQueueMessages="true"
/>
</deadLetterStrategy>
</policyEntry>
<policyEntries>
[...]
=====
So we have some queues; queue1, queue2 and so on. They all match the
first wildcard entry in the configuration and allows messages to jump
between our network of brokers even if they already been transfered from
the reciving broker already. (replayWhenNoConsumers="true")
Just as we want and expected.
Then we have this other queue, "just.another.queue" which requires some
more specific DLQ settings. But we still want the messages to been able
to jump between the brokers even if they have the reciving broker as
origin. This doesn't work. Our hope and exceptation was that the our
more queue specific entry would inheritance from the wildcard entry and
therfor allow messages jump freely. But the messages are stuck and TRACE
gives us "Message all ready routed once through target broker [...]".
Is this the way it should work? Is there any inheritance between
policies or is it most specific wins?
--
jocar
Re: policyEntries, inheritance and wildcards
Posted by Christopher Shannon <ch...@gmail.com>.
Right, there is no inheritance between policies or merging semantics as Tim
pointed out. So if you define a new policy then you need to re-apply all
the settings you want to the new policy as well.
On Fri, Jun 17, 2016 at 9:09 AM, Johan Carlquist <jo...@su.se> wrote:
> Thanks for your reply.
>
> It had been nice to avoid dublicated queue configuration so we will look
> in to make an JIRA enhancement request for this later this
> summer.
>
> --
> jocar
>
> > On 11 Jun 2016, at 17:43, Tim Bain <tb...@alumni.duke.edu> wrote:
> >
> > Sorry, I just re-read your description of the behavior and clearly it's
> not
> > first-match as I had believed. But I still believe that there are no
> > merging semantics available, so the solutions I described still apply
> > except for the statement that you need to reorder the list, which sounds
> > from your description like it should have no effect.
> > On Jun 11, 2016 9:38 AM, "Tim Bain" <tb...@alumni.duke.edu> wrote:
> >
> >> I believe the semantics are first-match, not
> >> merge-all-matches-overwriting-conflicts (e.g. how Spring loads
> properties)
> >> and not merge-all-matches-not-overwriting-conflicts (e.g. how Ant loads
> >> properties).
> >>
> >> You could request the ability to select a different semantic (which
> would
> >> require someone to implement any semantics other than first-match)
> through
> >> a JIRA enhancement request, if you want that. In the meantime, put your
> >> more-specific match first and include all the content of the generic
> case
> >> along with the things that are specific.
> >>
> >> Tim
> >> On Jun 10, 2016 2:54 AM, "Johan Carlquist" <jo...@su.se> wrote:
> >>
> >> Hi!
> >>
> >> Our config:
> >> =====
> >>
> >> [...]
> >> <policyEntries>
> >> <policyEntry queue=">" >
> >> <networkBridgeFilterFactory>
> >> <conditionalNetworkBridgeFilterFactory
> >> replayWhenNoConsumers="true"
> >> />
> >> </networkBridgeFilterFactory>
> >> </policyEntry>
> >> <policyEntry queue="just.another.queue">
> >> <deadLetterStrategy>
> >> <individualDeadLetterStrategy
> >> processExpired="true"
> >> processNonPersistent="true"
> >> queueSuffix=".DLQ"
> >> useQueueForQueueMessages="true"
> >> />
> >> </deadLetterStrategy>
> >> </policyEntry>
> >> <policyEntries>
> >> [...]
> >>
> >> =====
> >>
> >> So we have some queues; queue1, queue2 and so on. They all match the
> >> first wildcard entry in the configuration and allows messages to jump
> >> between our network of brokers even if they already been transfered from
> >> the reciving broker already. (replayWhenNoConsumers="true")
> >> Just as we want and expected.
> >>
> >> Then we have this other queue, "just.another.queue" which requires some
> >> more specific DLQ settings. But we still want the messages to been able
> >> to jump between the brokers even if they have the reciving broker as
> >> origin. This doesn't work. Our hope and exceptation was that the our
> >> more queue specific entry would inheritance from the wildcard entry and
> >> therfor allow messages jump freely. But the messages are stuck and TRACE
> >> gives us "Message all ready routed once through target broker [...]".
> >>
> >> Is this the way it should work? Is there any inheritance between
> >> policies or is it most specific wins?
> >>
> >> --
> >> jocar
>
>
Re: policyEntries, inheritance and wildcards
Posted by Johan Carlquist <jo...@su.se>.
Thanks for your reply.
It had been nice to avoid dublicated queue configuration so we will look
in to make an JIRA enhancement request for this later this
summer.
--
jocar
> On 11 Jun 2016, at 17:43, Tim Bain <tb...@alumni.duke.edu> wrote:
>
> Sorry, I just re-read your description of the behavior and clearly it's not
> first-match as I had believed. But I still believe that there are no
> merging semantics available, so the solutions I described still apply
> except for the statement that you need to reorder the list, which sounds
> from your description like it should have no effect.
> On Jun 11, 2016 9:38 AM, "Tim Bain" <tb...@alumni.duke.edu> wrote:
>
>> I believe the semantics are first-match, not
>> merge-all-matches-overwriting-conflicts (e.g. how Spring loads properties)
>> and not merge-all-matches-not-overwriting-conflicts (e.g. how Ant loads
>> properties).
>>
>> You could request the ability to select a different semantic (which would
>> require someone to implement any semantics other than first-match) through
>> a JIRA enhancement request, if you want that. In the meantime, put your
>> more-specific match first and include all the content of the generic case
>> along with the things that are specific.
>>
>> Tim
>> On Jun 10, 2016 2:54 AM, "Johan Carlquist" <jo...@su.se> wrote:
>>
>> Hi!
>>
>> Our config:
>> =====
>>
>> [...]
>> <policyEntries>
>> <policyEntry queue=">" >
>> <networkBridgeFilterFactory>
>> <conditionalNetworkBridgeFilterFactory
>> replayWhenNoConsumers="true"
>> />
>> </networkBridgeFilterFactory>
>> </policyEntry>
>> <policyEntry queue="just.another.queue">
>> <deadLetterStrategy>
>> <individualDeadLetterStrategy
>> processExpired="true"
>> processNonPersistent="true"
>> queueSuffix=".DLQ"
>> useQueueForQueueMessages="true"
>> />
>> </deadLetterStrategy>
>> </policyEntry>
>> <policyEntries>
>> [...]
>>
>> =====
>>
>> So we have some queues; queue1, queue2 and so on. They all match the
>> first wildcard entry in the configuration and allows messages to jump
>> between our network of brokers even if they already been transfered from
>> the reciving broker already. (replayWhenNoConsumers="true")
>> Just as we want and expected.
>>
>> Then we have this other queue, "just.another.queue" which requires some
>> more specific DLQ settings. But we still want the messages to been able
>> to jump between the brokers even if they have the reciving broker as
>> origin. This doesn't work. Our hope and exceptation was that the our
>> more queue specific entry would inheritance from the wildcard entry and
>> therfor allow messages jump freely. But the messages are stuck and TRACE
>> gives us "Message all ready routed once through target broker [...]".
>>
>> Is this the way it should work? Is there any inheritance between
>> policies or is it most specific wins?
>>
>> --
>> jocar
Re: policyEntries, inheritance and wildcards
Posted by Tim Bain <tb...@alumni.duke.edu>.
Sorry, I just re-read your description of the behavior and clearly it's not
first-match as I had believed. But I still believe that there are no
merging semantics available, so the solutions I described still apply
except for the statement that you need to reorder the list, which sounds
from your description like it should have no effect.
On Jun 11, 2016 9:38 AM, "Tim Bain" <tb...@alumni.duke.edu> wrote:
> I believe the semantics are first-match, not
> merge-all-matches-overwriting-conflicts (e.g. how Spring loads properties)
> and not merge-all-matches-not-overwriting-conflicts (e.g. how Ant loads
> properties).
>
> You could request the ability to select a different semantic (which would
> require someone to implement any semantics other than first-match) through
> a JIRA enhancement request, if you want that. In the meantime, put your
> more-specific match first and include all the content of the generic case
> along with the things that are specific.
>
> Tim
> On Jun 10, 2016 2:54 AM, "Johan Carlquist" <jo...@su.se> wrote:
>
> Hi!
>
> Our config:
> =====
>
> [...]
> <policyEntries>
> <policyEntry queue=">" >
> <networkBridgeFilterFactory>
> <conditionalNetworkBridgeFilterFactory
> replayWhenNoConsumers="true"
> />
> </networkBridgeFilterFactory>
> </policyEntry>
> <policyEntry queue="just.another.queue">
> <deadLetterStrategy>
> <individualDeadLetterStrategy
> processExpired="true"
> processNonPersistent="true"
> queueSuffix=".DLQ"
> useQueueForQueueMessages="true"
> />
> </deadLetterStrategy>
> </policyEntry>
> <policyEntries>
> [...]
>
> =====
>
> So we have some queues; queue1, queue2 and so on. They all match the
> first wildcard entry in the configuration and allows messages to jump
> between our network of brokers even if they already been transfered from
> the reciving broker already. (replayWhenNoConsumers="true")
> Just as we want and expected.
>
> Then we have this other queue, "just.another.queue" which requires some
> more specific DLQ settings. But we still want the messages to been able
> to jump between the brokers even if they have the reciving broker as
> origin. This doesn't work. Our hope and exceptation was that the our
> more queue specific entry would inheritance from the wildcard entry and
> therfor allow messages jump freely. But the messages are stuck and TRACE
> gives us "Message all ready routed once through target broker [...]".
>
> Is this the way it should work? Is there any inheritance between
> policies or is it most specific wins?
>
> --
> jocar
>
>
Re: policyEntries, inheritance and wildcards
Posted by Tim Bain <tb...@alumni.duke.edu>.
I believe the semantics are first-match, not
merge-all-matches-overwriting-conflicts (e.g. how Spring loads properties)
and not merge-all-matches-not-overwriting-conflicts (e.g. how Ant loads
properties).
You could request the ability to select a different semantic (which would
require someone to implement any semantics other than first-match) through
a JIRA enhancement request, if you want that. In the meantime, put your
more-specific match first and include all the content of the generic case
along with the things that are specific.
Tim
On Jun 10, 2016 2:54 AM, "Johan Carlquist" <jo...@su.se> wrote:
Hi!
Our config:
=====
[...]
<policyEntries>
<policyEntry queue=">" >
<networkBridgeFilterFactory>
<conditionalNetworkBridgeFilterFactory
replayWhenNoConsumers="true"
/>
</networkBridgeFilterFactory>
</policyEntry>
<policyEntry queue="just.another.queue">
<deadLetterStrategy>
<individualDeadLetterStrategy
processExpired="true"
processNonPersistent="true"
queueSuffix=".DLQ"
useQueueForQueueMessages="true"
/>
</deadLetterStrategy>
</policyEntry>
<policyEntries>
[...]
=====
So we have some queues; queue1, queue2 and so on. They all match the
first wildcard entry in the configuration and allows messages to jump
between our network of brokers even if they already been transfered from
the reciving broker already. (replayWhenNoConsumers="true")
Just as we want and expected.
Then we have this other queue, "just.another.queue" which requires some
more specific DLQ settings. But we still want the messages to been able
to jump between the brokers even if they have the reciving broker as
origin. This doesn't work. Our hope and exceptation was that the our
more queue specific entry would inheritance from the wildcard entry and
therfor allow messages jump freely. But the messages are stuck and TRACE
gives us "Message all ready routed once through target broker [...]".
Is this the way it should work? Is there any inheritance between
policies or is it most specific wins?
--
jocar