Concur!
On Tuesday, May 7, 2013, Paul Gale wrote:
> Hi Christian,
>
> So after looking through ActiveMQ's code it would appear that my
> understanding of what constitutes a 'default entry*'* is not what I had
> previously thought. As stated previously I thought that a 'default entry'
> was used to define default configuration values that would be subsequently
> *
> inherited* by specific topic and queue policy entries. The idea being that
> these policy entries could optionally override these configuration values.
> In other words I was interpreting 'default' to mean 'base'. This I now
> know, is wrong.
>
> It turns out that the default entry is not used for inheriting
> configuration at all. Rather it is used (if defined) to configure either a
> topic or queue destination when there is no corresponding destination
> policy. Searching for a corresponding destination policy involves wildcard
> matching the list of policy entries. Given that I have wildcard policy
> entries for both topics and queues with the widest possible scope ('>') the
> defaultEntry will NEVER be used, as the wildcard always results in a match.
>
> Below is the only place that the defaultEntry is retrieved (in
> PolicyMap.java):
>
> public PolicyEntry getEntryFor(ActiveMQDestination destination) {
> PolicyEntry answer = (PolicyEntry) chooseValue(destination);
> if (answer == null) {
> answer = getDefaultEntry();
> }
> return answer;
> }
>
> Do you concur with my findings?
>
> Thanks,
> Paul
>
>
> On Tue, May 7, 2013 at 11:42 AM, Christian Posta
> <[email protected] <javascript:;>>wrote:
>
> > Paul,
> >
> > Looks like you have a policy for all queues and all topics too... So the
> > default policy won't get used for those destinations. I think you also
> have
> > to specify a "topic" or "queue" for default entry, even though it gets
> > ignored.
> >
> >
> > On Tue, May 7, 2013 at 8:09 AM, Paul Gale
> > <[email protected]<javascript:;>>
> wrote:
> >
> > > Hi,
> > >
> > > In an attempt to DRY up my ActiveMQ configuration I realized that,
> > > according to the activemq-core schema, it's possible to configure
> common
> > > defaults for both topics and queues as shown in the snippet below. I
> have
> > > this defined in my activemq.xml currently.
> > >
> > > Whilst ActiveMQ does not fail the schema validation on startup I still
> > > don't know whether ActiveMQ has honored these settings or has ignored
> > them.
> > > I have not come across any references to this method of configuring
> > common
> > > defaults, nor do I have a way to verify that said configuration has
> taken
> > > effect the way I think it has, short of relying on any explicit logging
> > > statements. Would exploring ActiveMQ's MBeans via JMX be the best
> method
> > > for verification?
> > >
> > > Can one of the committers comment on the legality of this syntax?
> > >
> > > Thanks,
> > > Paul
> > >
> > >
> >
> ____________________________________________________________________________________________________
> > >
> > > <destinationPolicy>
> > > <policyMap>
> > > <defaultEntry>
> > > <policyEntry producerFlowControl="false"
> > > advisoryWhenFull="true"
> > > advisoryForFastProducers="true"
> > > advisoryForSlowConsumers="true"
> > > advisoryForDiscardingMessages="true"
> > > optimizedDispatch="true">
> > > <deadLetterStrategy>
> > > <individualDeadLetterStrategy queuePrefix="DLQ."
> > > topicPrefix="DLQ."
> > > processExpired="false"
> > >
> > useQueueForQueueMessages="true"
> > >
> > useQueueForTopicMessages="true"
> > >
> > > destinationPerDurableSubscriber="false"/>
> > > </deadLetterStrategy>
> > > <dispatchPolicy>
> > > <roundRobinDispatchPolicy/>
> > > </dispatchPolicy>
> > > </policyEntry>
> > > </defaultEntry>
> > > <policyEntries>
> > > <policyEntry topic=">">
> > > <dispatchPolicy>
> > > <strictOrderDispatchPolicy/>
> > > </dispatchPolicy>
> > > </policyEntry>
> > > <policyEntry queue=">" />
> > > </policyEntries>
> > > </policyMap>
> > > </destinationPolicy>
> > >
> >
> >
> >
> > --
> > *Christian Posta*
> > http://www.christianposta.com/blog
> > twitter: @christianposta
> >
>
--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
