>
> I was expecting to see no traffic of any kind on our hub concerning
> Outbound.Account.>, yet sub requests are still flooding in.
Can you explain more what you mean? Do you see subs being created for that
dest on the networked brokers?
If what you mean is you're seeing the logs below, that's as intended. When
a bridge is established, it will listen to the remote broker's consumer
advisory messages (it listens to all of them, they are not filtered). If it
sees a consumerInfo come in for a destination that is excluded, it will
just ignore it and log the message you see below. This is by design, at the
moment.
On Mon, Oct 29, 2012 at 5:59 AM, James Green <james.mk.gr...@gmail.com>wrote:
> Given:
>
> <networkConnectors>
> <networkConnector uri="static://(ssl://hub:61617)"
> name="hub"
> duplex="true"
> conduitSubscriptions="false"
> dynamicOnly="false">
> <excludedDestinations>
> <queue physicalName="Outbound.Account.>"/>
> </excludedDestinations>
> <staticallyIncludedDestinations>
> </staticallyIncludedDestinations>
> </networkConnector>
> </networkConnectors>
>
> On "hub" I see:
>
> 2012-10-29 12:44:34,722 | DEBUG | hub Ignoring sub from zorin, destination
> queue://Outbound.Account.20481 is not permiited :ConsumerInfo {commandId =
> 5, responseRequired = false, consumerId =
> ID:quarrel-40451-1351260922652-4:760216:-1:2, destination =
> queue://Outbound.Account.20481, prefetchSize = 1,
> maximumPendingMessageLimit = 0, browser = false, dispatchAsync = true,
> selector = MJStage = 'Dispatch', subscriptionName = null, noLocal = false,
> exclusive = false, retroactive = false, priority = 0, brokerPath = null,
> optimizedAcknowledge = false, noRangeAcks = false, additionalPredicate =
> null} | org.apache.activemq.network.DemandForwardingBridgeSupport |
> ActiveMQ Transport: ssl:///n.n.n.n:32831
>
> I was expecting to see no traffic of any kind on our hub concerning
> Outbound.Account.>, yet sub requests are still flooding in.
>
> Is this normal? Can I get my desired result?
>
> Thanks,
>
> James
>
--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
