Gordon,

Thank you very much for your answer. Please see my comments and further
questions below:

On Mon, Feb 1, 2016 at 3:45 AM, Gordon Sim <g...@redhat.com> wrote:

> On 01/31/2016 10:19 PM, jjw tectec wrote:
>
>> I sent out the email more than 3 days ago, but it's still not appearing
>> in the mailing list. Has it been deleted from the archive?
>>
>
> I got the mail, but not the attached image. I actually thought I had
> replied as well, but it appears not...
>
> On Thu, Jan 28, 2016 at 1:02 PM, jjw tectec <jjw.tec...@gmail.com
>> <mailto:jjw.tec...@gmail.com>> wrote:
>>
>>     I've set up a simple 4-broker system, where between Bs (source
>>     broker) and Bd (destination broker) are two middle brokers set up in
>>     parallel, like this:
>>
>>     Inline image 1
>>
>>     The script that I used to set up all the resources & routes is shown
>>     at the end of this message.
>>     I attached a publisher to Bs and attached 3 subscribers to the other
>>     3 brokers.
>>     What I was expecting to see was all 3 brokers should see messages.
>>     The actual observation was: Only B1 and Bf received messages. B2
>>     never received messages, even when B1 was down.
>>
>>     route map showed that all broker connections were set up as
>>     expected, but why would only the first route work and not the other?
>>     (I have added more brokers B3 B4... into the test, always, only the
>>     first established route would work.) Please help.
>>
>
> Without the picture I'm not entirely sure I'm correctly understanding your
> system. However it sounds like it may be the fact that messages from a
> queue are not broadcast to all subscribers; the consumers compete for the
> messages and each message goes to only one of them.
>

Sorry the image didn't show up. My broker setup was below:

Bs Queue
              |---------> B1->Exchange->Queue |---------------->Bd Exchange
              |                                               |
              |------> B2->Exchange->Queue ---|

Since between Bs and Bd there are two alternative routes, I was expecting
messages to be duplicated in the two routes (according to the behavior
described in the C++ Broker Manual).
The actual behavior was: only the first established route had the messages.
I followed your suggestions (by adding ack and sending large numbers of
messages in a loop), but observed the same behavior: Route 1 was the only
route receiving all messages. If I shut down B1, then messages are queued
up in Bs's Queue until B1 is brought up again.

I remember that some time ago, I did see round robin kind of behavior (B1
and B2 were getting messages alternately), with a slightly different test
setup. Now I can not replicate that anymore.

Your figure below suggested creating individual queues for each downstream
broker. This is not what I wanted. I wanted a single queue in the upstream
broker, and the desired behavior that my application need is:
      Messages will flow through the first established route, say B1. But
whenever B1 is down, then messages would automatically switch to the second
route, say B2. (we need a "one and only one route" kind of behavior).

Is this something I could achieve using static queue routes alone? I've
felt that I probably need to write a shovel module between Bs and B1/B2 to
make the selection or any load balancing happen.
If I'm heading in a wrong direction, please kindly suggest a good path. :)

Thanks

jjw


>
> For small numbers of messages the same consumer may end up getting them
> all. For larger numbers there should normally be more fair balancing. You
> can improve the balance a little with the --ack option to qpid-route (which
> controls the acking frequency and also prefetch).
>
> To use queue routes with a fanout, you would need to create and bind a
> queue for each downstream broker. E.g.
>
>
> B1->Exchange
>     |
>     |-> queue1     ---------> B2->Exchange
>     |-> queue2     ---
>                      |
>                      |------> B3->Exchange
>
> etc
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Reply via email to