activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Shannon <christopher.l.shan...@gmail.com>
Subject Re: policyEntries, inheritance and wildcards
Date Fri, 17 Jun 2016 14:04:26 GMT
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 <jocar@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 <tbain@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" <tbain@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" <jocar@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message