Do you have any evidence that advisory messages about hundreds of empty
queues actually has a measurable impact on either your central broker or
your edge brokers? It's definitely possible that the overhead of advisory
messages really is too high, but if you haven't measured it somehow and
you're just going with your gut on this, there's a very good chance you're
doing premature optimization. The path you're going down has pain points
(some of which you've found), so if you don't need to go down it, you
should save yourself the trouble and let your brokers worry about message
routing instead worrying about it for them.
Statically including all destinations will send messages for all
destinations to the central broker when all consumers are offline, even if
the consumers will only ever be on the local broker. That doesn't sound
like what you want, particularly because the default configuration doesn't
allow messages to go back to a broker they've already been to.
I thought you'd have just dynamically included those destinations that can
have non-local consumers; is there a reason that's not the path you're
going down?
Setting the dynamically included destinations from the local broker side of
the duplex connections should be fine; you're trying to limit the ability
for certain messages to escape the local broker, not prevent the central
broker from passing on messages (which couldn't happen anyway if all local
brokers are properly configured).
Tim
On Oct 29, 2015 11:28 AM, "Jako" <i...@simone.pro> wrote:
> Hi Tim,
> thank you for your replay and your very thoughtful questions.
>
> >But are you sure you need to? Are you sure this isn't a premature [...]
>
> I think so. The central broker is on our server farm and it is very
> resourceful machine; anyway it often uses a lot of cpu. The broker uses
> thousands of threads.
> Beside this, the external brokers are on cheap hardware and I think the
> advisory messages about hundreds queues are too much.
> In any case those information doesn't really belong there; those computers
> are not fully trusted.
> And sometimes the network don't behave very well: some messages are lost.
>
> I'm not sure the issue of the lost messages arises from the ActiveMQ
> network, but I want to clean up things and have a more appropriate
> structure.
>
> Yesterday I tried a lot of combinations with some success.
> But I really didn't land to a final and satisfactory configuration.
>
> The best I could hope for is a sort of 'default gateway', making an analogy
> to the ip protocol.
>
> I tried to emulate that using a staticallyIncludedDestinations(">") queue
> and using decreaseNetworkConsumerPriority(true). But this had side effects.
> And many others configurations...
>
> I wonder one thing, among others: the network-connector of the external
> brokers are in full-duplex mode and I'm able to setup many parameters:
> consumerTTL, staticallyIncludedDestinations, staticBridge.
> But, I can't do it in the reverse direction.
> In other words, to have the same options I think I should make the
> network-connector from the H central broker to the external brokers. It
> would be nice to able to specify in the H center broker that it had to
> prefer local consumer (I did it with decreaseNetworkConsumerPriority) but I
> don't know how to set that in the central broker.
>
> Maybe I'm rambling a bit, because I tried a lot of different
> configurations,
> avoiding the static routing; I couldn't use it because it's not possible to
> know in advance the network structure.
>
> Thank you again
>
> Simone
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Hub-and-spoke-network-topology-tp4703434p4703491.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
