To close my previous question, I'd like to say it
seems to work well to let the backend servers connect
to each of the frontend brokers like I planned:
frontend1
embedded broker
queue1 (producer)
frontend2
embedded broker
queue2 (producer)
backend1
connection to frontend1 broker
queue1 (consumer)
connection to frontend2 broker
queue2 (consumer)
backend2
connection to frontend1 broker
queue1 (consumer)
connection to frontend2 broker
queue2 (consumer)
Currently I'm specifying connections with explicit IP
addresses but I might look into using discovery.
Best regards
Mike
Mike Wilson wrote:
> I'm looking for help in choosing a broker topology for
> our system with <M> frontend servers sending messages
> to <N> backend servers.
>
> We want to minimize network bandwidth so want a
> solution where a (successful) message is only
> transferred in one copy over one network hop.
>
> This means I'm looking at a solution with embedded
> brokers. We're also considering using MessageGroups
> so the network of brokers topology is probably not
> possible.
>
> I'm thinking that we could embed a broker in every
> frontend server, and let backend servers connect to
> all brokers. It's ok to lose all messages for a
> frontend server if it goes down.
>
> But what about having the backend servers being
> separately load-balanced over <M> different brokers;
> is that setup even possible and does it cause unwanted
> effects?
>
> Thanks
> Mike
